Reducing false positive fraud alerts for online financial transactions

ABSTRACT

In a method of preventing fraudulent online financial transactions, a request to authorize an online, financial transaction may be received, where the transaction is associated with a debit or credit card account. A computing device at which information associated with the debit or credit card account was entered for the transaction may be identified, and a first geographic location at which the computing device resides may be determined. Based upon geolocation data indicating one or more geographic locations of the authorized cardholder, it may be determined that the authorized cardholder was at a second geographic location at a time of the transaction. If the second geographic location does not correspond to the first geographic location, the financial transaction may be prevented from being executed.

CROSS-REFERENCE TO RELATED APPLICATIONS

This claims the benefit of U.S. Patent Application No. 62/313,196, filedon Mar. 25, 2016 and entitled “Reducing Financial Fraud Using MachineLearning and Other Techniques,” U.S. Patent Application No. 62/318,423,filed on Apr. 5, 2016 and entitled “Reducing Financial Fraud UsingMachine Learning and Other Techniques,” U.S. Patent Application No.62/331,530, filed on May 4, 2016 and entitled “Reducing Financial FraudUsing Machine Learning and Other Techniques,” and U.S. PatentApplication No. 62/365,699, filed on Jul. 22, 2016 and entitled“Detecting and/or Preventing Financial Fraud Using Geolocation Data,”the disclosures of which are hereby incorporated herein by reference intheir entireties.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to financial fraud and, morespecifically, to processing techniques for reducing false positive fraudalerts.

BACKGROUND

Financial fraud, in its many forms, is a problem of enormous magnitudeand scope, causing billions of dollars in economic losses and impactingmany millions of people. Types of financial fraud include use of a lostor stolen card, account takeover, skimming, chargeback (“friendly”)fraud, counterfeiting, forgeries and application (e.g., loanapplication) fraud, to name just a few. The problem only continues togrow as various technological advances, intended to improve convenienceand efficiency in the marketplace, provide new opportunities for badactors. For example, an ever-increasing amount of fraud may be linked toonline transactions made via the Internet.

Various software applications have been developed to detect potentiallyfraudulent transactions. For example, dollar amounts and geographiclocations have generally been used to flag particular credit or debitcard transactions, with cardholders then being contacted by employees ofthe card issuer to determine whether the transactions were indeedfraudulent. To ensure that most instances of fraud are captured,however, such techniques generally have a low threshold for triggering afraud alert. As a result, numerous fraud alerts are false positives. Theprevalence of false positives leads to a large cost in terms of thedrain on human resources (e.g., calling customers to discuss eachsuspect transaction, and/or other manual investigation techniques), andconsiderable distraction or annoyance for cardholders. To provide asolution to these shortcomings in the field of automated frauddetection, innovative processing techniques capable of reducing falsepositives are needed.

BRIEF SUMMARY

The present embodiments may, inter alia, use new processing techniquesto reduce false positive fraud alerts. For example, fraud alerts may begenerated, or fraud alerts based upon various other triggers (e.g.,presence of a large transaction, presence of a transaction initiated ina different state or country, cardholder reporting of unrecognized orfraudulent charges, etc.) may be either confirmed or ruled out (e.g.,identified as a false positive), using location information.

In one embodiment, a method of preventing fraudulent online financialtransactions is implemented in one or more servers. The method mayinclude: (1) receiving, by one or more processors of the one or moreservers, a request to authorize a financial transaction, wherein thefinancial transaction (i) is associated with a debit or credit cardaccount and (ii) is an online transaction purportedly being entered intoby an authorized cardholder associated with the debit or credit cardaccount; (2) identifying, by the one or more processors, a computingdevice at which information associated with the debit or credit cardaccount was entered in connection with the financial transaction; (3)determining, by the one or more processors, a first geographic locationat which the computing device resides; (4) determining, by the one ormore processors and based upon geolocation data indicating one or moregeographic locations of the authorized cardholder, that the authorizedcardholder was at a second geographic location at a time of thefinancial transaction; (5) determining, by the one or more processors,that the second geographic location does not correspond to the firstgeographic location; and/or (6) in response to determining that thesecond geographic location does not correspond to the first geographiclocation, preventing, by the one or more processors, the financialtransaction from being executed. The method may include additional,less, or alternate actions, including those discussed elsewhere herein.

In another embodiment, a computer system for preventing fraudulentonline financial transactions includes a location database configured tostore geolocation data indicating geographic locations of authorizedcardholders over time, one or more processors, and a non-transitorymemory. The memory stores instructions that, when executed by the one ormore processors, cause the one or more processors to: (1) receive arequest to authorize a financial transaction, wherein the financialtransaction (i) is associated with a debit or credit card account and(ii) is an online transaction purportedly being entered into by anauthorized cardholder associated with the debit or credit card account;(2) identify a computing device at which information associated with thedebit or credit card account was entered in connection with thefinancial transaction; (3) determine a first geographic location atwhich the computing device resides; (4) determine, based upongeolocation data indicating one or more geographic locations of theauthorized cardholder, that the authorized cardholder was at a secondgeographic location at a time of the financial transaction; (5)determine that the second geographic location does not correspond to thefirst geographic location; and/or (6) in response to determining thatthe second geographic location does not correspond to the firstgeographic location, prevent the financial transaction from beingexecuted. The computer system may include additional, less, or alternatefunctionality, including that discussed elsewhere herein.

In another embodiment, a method of reducing false positives amonggeolocation-based fraud alerts issued in connection with onlinefinancial transactions is implemented in one or more servers. The methodmay include: (1) determining, by one or more processors of the one ormore servers, that a fraud alert exists for a financial transaction,wherein the financial transaction (i) is associated with a debit orcredit card account and (ii) is an online transaction purportedlyentered into by an authorized cardholder associated with the debit orcredit card account; (2) identifying, by the one or more processors, acomputing device at which information associated with the debit orcredit card account was entered in connection with the financialtransaction; (3) determining, by the one or more processors, a firstgeographic location at which the computing device resides; (4)determining, by the one or more processors, a time of the financialtransaction; (5) determining, by the one or more processors and basedupon geolocation data indicating one or more geographic locations of theauthorized cardholder, that the authorized cardholder was at a secondgeographic location at the time of the financial transaction; (6)determining, by the one or more processors, that the second geographiclocation corresponds to the first geographic location; and/or (7) inresponse to determining that the second geographic location correspondsto the first geographic location, marking, by the one or moreprocessors, the fraud alert as a false positive such that no fraud alertis sent to the authorized cardholder in connection with the financialtransaction. The method may include additional, less, or alternateactions, including those discussed elsewhere herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The Figures described below depict various aspects of the systems andmethods disclosed herein. It should be understood that each Figuredepicts an embodiment of a particular aspect of the disclosed systemsand methods, and that each of the Figures is intended to accord with apossible embodiment thereof.

FIG. 1 depicts an exemplary environment in which techniques for frauddetection, verification and/or classification may be implemented,according to one embodiment.

FIG. 2 depicts an exemplary process flow for machine learning of frauddetection, verification and/or classification rules, according to oneembodiment.

FIGS. 3A-3F depict exemplary process flows for machine learning ofparticular types of fraud detection, verification and/or classificationrules, according to different embodiments.

FIGS. 4A-4F depict exemplary factors and algorithms that may be used inconnection with various fraud detection, verification and/orclassification rule sets, according to different embodiments.

FIGS. 5 and 6 illustrate exemplary computer-implemented methods of usingcustomer data to determine that geolocation-based fraud alerts are falsepositives, according to different embodiments.

FIGS. 7 through 10 illustrate exemplary computer-implemented methods ofusing information about the locations of authorized cardholders toprevent false positive fraud alerts, or to block potentially fraudulentfinancial transactions, according to different embodiments.

FIG. 11 depicts an exemplary computer system in which the techniquesdescribed herein may be implemented, according to one embodiment.

DETAILED DESCRIPTION I. Exemplary Fraud Detection and/or Classification

The embodiments described herein relate to, inter alia, wholly orpartially automated detection, verification and/or classification offinancial fraud. For ease of explanation, and unless otherwise clearlyindicated by the context of usage, “detecting” or “determining” fraudmay be used herein to refer to initially flagging fraudulent (orpotentially fraudulent) activity, to verifying/confirming thatsuspect/flagged activity was indeed fraudulent, or generally to both.The systems and techniques described herein may be used, for example, toidentify, prevent and/or quantify/measure instances of lost or stolencard use, account takeover, counterfeiting, skimming, chargeback(“friendly”) fraud, collusive merchant fraud, application (e.g., loanapplication) fraud, mortgage fraud, and/or one or more other types offraud relating to existing and/or potential financial transactionsand/or accounts. Moreover, those skilled in the art will appreciate thatat least some of the technical advancements described below (and/orshown in the accompanying figures) are not necessarily restricted to thefinancial field.

In some embodiments, a fraud detection and/or classification system mayanalyze data relating to a number of existing or potential financialaccounts. The analysis/processing may be performed in batch processingoperations, or substantially in real-time (e.g., as the data isgenerated and/or as financial transactions occur, etc.), and the datamay be obtained from a variety of sources based upon the particularembodiment and/or scenario. In one embodiment, for example, data fromfinancial account records may be analyzed, along with data indicatingonline activity of an account holder, location data (e.g., globalpositioning satellite (GPS) data from a smartphone or vehicle of theaccount holder) and/or other data, to determine whether a particularfinancial transaction was fraudulent or likely fraudulent. The analysismay be performed automatically after the transaction has been made, ormay be performed in response to a person or algorithm flagging thetransaction as a potentially fraudulent one, for example.

The analysis may include determining whether the account holder hasexpressed interest in the object (e.g., product or service) of thetransaction or the merchant, and/or determining whether the transactionis consistent with spending patterns associated with the account holder(e.g., spending patterns identified using the account holder'stransaction records), for example. In the case of multiple accountholders (e.g. multiple credit or debit card holders), accuracy may beimproved by identifying spending patterns at the individual level ratherthan, or in addition to, at the aggregate account level. For example, amaximum amount of money typically spent in a single transaction (e.g.,over the course of a one-month window, etc.) may be determined for eachof two cardholders listed on a single account, and the maximum amountfor the cardholder who purportedly made a particular purchase may becompared to the purchase amount to determine whether fraud is suspected.

In another exemplary embodiment, the locations of authorized cardholdersmay be analyzed, in conjunction with the locations at which cards werepresented to a merchant or merchant device (if a card-presenttransaction) or the locations of computing devices via which cardinformation was entered (if an online transaction), to determine whethera fraud alert is likely a false positive. Alternatively, such locationsmay be analyzed to determine whether to block a transaction that iscurrently in-process (e.g., by issuing a fraud alert to the merchant orcard issuer, or by not clearing the transaction, etc.).

By replacing conventional processing techniques with one or more of theprocessing techniques described herein, problems that have beset thefield of fraud detection, classification and/or prevention in the pastmay be greatly mitigated or eliminated. For example, information thathas conventionally been overlooked or ignored may be used to moreaccurately detect, prevent and/or classify fraud, and/or to reduce falsepositive fraud alerts. As another example, a significant amount of timemay be saved by removing the need for manual investigations, or byreducing the number of instances where manual investigations arerequired.

II. Exemplary Environment for Implementing Fraud Detection and/orClassification Processing Techniques

FIG. 1 depicts an exemplary environment 10 in which techniques for frauddetection and/or classification may be implemented, according to oneembodiment. The environment 10 may include an anti-fraud services system(AFSS) 12, a financial account management system (FAMS) 14, a cardnetwork computing system 16, a number of cardholder computing devices20, a number of merchant computing systems 22, a number of other sources24, and a network 26. It is noted that, in other embodiments and/orscenarios, the environment 10 may include more, fewer and/or differentcomponents than those shown in FIG. 1, such as any of those discussedelsewhere herein. For example, the environment 10 may include one ormore additional financial account management systems and/or card networkcomputing systems, and/or one or more of the cardholder computingdevices 20 may instead be a computing device of a holder of a non-cardaccount (e.g., a checking, savings or loan account) or an applicant fora new account (e.g., a new loan account). As another example, theenvironment 10 may include a computing system of one or moreacquiring/merchant banks, and some or all of the communications withmerchant computing systems 22 described below may instead be with theacquiring bank(s).

FAMS 14 may be associated with (e.g., owned and/or maintained by) a bankor other financial entity. For example, FAMS 14 may be a bank that actsas a card issuer associated with a particular type of card network(e.g., VISA®, Mastercard®, etc.), and/or an entity that provides loans(e.g., mortgage, home equity, vehicle, etc.), saving/checking accountservices, and/or other financial services to customers. FAMS 14 maymaintain an account records database 30 that stores various kinds ofaccount information, including account holder information (e.g., names,addresses, etc.) and data indicative of financial transactions made inconnection with each account (e.g., dates, amounts and merchants forcredit or debit card transactions, dates and amounts for customerdeposits and withdrawals, etc.). Account records database 30 may storeaccount information for some or all of the cardholders associated withcardholder computing devices 20, for example. While shown in FIG. 1 as asingle entity within FAMS 14, it is understood that account recordsdatabase 30 may, in some embodiments, be distributed across multipledatabases and/or multiple physical/hardware memories, and/or may bewholly or partially external to (e.g., remote from) FAMS 14.

AFSS 12 may generally provide services that help to detect and/orclassify fraudulent activity in connection with existing and/orpotential (e.g., applied for) financial accounts, such as the accountsmanaged by FAMS 14. In some embodiments, AFSS 12 is included within FAMS14. As seen in FIG. 1, AFSS 12 may include a network interface 32, amemory 34, and a fraud detection/classification unit 36.

Network interface 32 may include hardware, firmware and/or softwareconfigured to enable AFSS 12 to wirelessly exchange electronic data withone or more other components of environment 10 via network 26. Forexample, network interface 32 may include an Ethernet port, a modem, arouter, and/or one or more other ports and/or transceivers for one ormore other wired and/or wireless communication technologies.

Memory 34 may be a computer-readable, non-transitory storage unit ordevice, or collection of units/devices, and may include persistent(e.g., hard disk) and/or non-persistent memory components. Memory 34 maystore instructions that are executable on one or more processors of AFSS12 (not shown in FIG. 1) to perform various operations, including theinstructions of various software applications and data generated and/orused by such applications.

Card network computing system 16 may be a computing system (e.g., one ormore servers) of a credit and/or debit card network entity, such asVISA® or Mastercard®, for example. In some embodiments and/or scenarioswhere the card network entity also acts as the issuer (e.g., AmericanExpress® or Discover®), card network computing system 16 may includeFAMS 14. Card network computing system 16 may provide various servicesto FAMS 14 and/or AFSS 12. For example, card network computing system 16may provide electronic updates to chargeback rules, fraud scores forparticular customers and/or transactions, and so on.

Each of cardholder computing devices 20 may be a computing device of arespective holder of a credit or debit card account managed by FAMS 14.For example, one or more of cardholder computing devices 20 may bedesktop computers, laptop computers, tablet computers, smartphones,smart watches, and so on. The cardholders (e.g., credit or debit cardaccount holders) may use cardholder computing devices 20 to access(e.g., view, modify, etc.) their account information stored in accountrecords database 30 online via network 26. In some embodiments whereAFSS 12 detects and/or classifies activity not related to credit ordebit card fraud (e.g., a fraudulent application for a home equity loan,etc.), cardholder computing devices 20 may instead be computing devicesof other types of customers or potential customers, such as holders ofnon-card-based accounts, or individuals who have submitted an onlineapplication for a loan, etc., as discussed further below. In some ofthese embodiments, the environment 10 may omit card network computingsystem 16.

Each of merchant computing systems 22 may include one or more computingdevices associated with a particular provider of products and/orservices. For example, some or all of merchant computing systems 22 mayinclude servers associated with online retailers. Alternatively, oradditionally, some or all of merchant computing systems 22 may includepoint-of-sale terminal devices providing credit and/or debit cardpayment processing features for “card present” transactions. In someembodiments where AFSS 12 detects and/or classifies activity not relatedto customer purchases (e.g., if AFSS 12 only detects loan applicationfraud, etc.), the environment 10 may omit merchant computing systems 22.

The other sources 24 may include computing devices and/or systemsassociated with sources of one or more other types of information. Forexample, other sources 24 may include vehicle telematics systems (e.g.,installed in vehicles of cardholders associated with cardholdercomputing devices 20), one or more Internet service providers (ISPs)(e.g., ISPs providing Internet access to some or all cardholders),“smart home” system devices (e.g., installed in homes of some or allcardholders), and/or other systems/devices. In some embodiments, theenvironment 10 does not include the other sources 24.

Network 26 may communicatively couple some or all of the componentsshown in FIG. 1. For example, FAMS 14 may use network 26 to communicatewith AFSS 12, card network computing system 16, cardholder computingdevices 20 and/or merchant computing systems 22. As another example,AFSS 12 may use network 26 to communicate with FAMS 14, card networkcomputing system 16, cardholder computing devices 20, merchant computingsystems 22 and/or one or more of the other sources 24. While shown as asingle entity in FIG. 1, network 26 may include multiple communicationnetworks of one or more types (e.g., one or more wired and/or wirelesslocal area networks (LANs), and/or one or more wired and/or wirelesswide area networks (WANs) such as the Internet). Moreover, network 26may use partially or entirely distinct network components to supportcommunications between different endpoints or computing devices, such aswireless communication or data transmission over one or more radiofrequency links and/or wireless communication channels. For example, theportion(s) of network 26 used for communications between FAMS 14 andAFSS 12 may be the same as, or different than, the portion(s) of network26 used for communications between FAMS 14 and one or more of cardholdercomputing devices 20 over one or more radio links or wirelesscommunication channels, or between AFSS 12 and one or more of the othersources 24, etc. Those skilled in the art will appreciate differenttypes of networks that are appropriate for network 26, depending upon,for example, how AFSS 12, FAMS 14 and/or other components of environment10 are localized or distributed across a relatively large geographicarea.

Generally, fraud detection/classification unit 36 of AFSS 12 may detectfraudulent activity, confirm whether suspected or reported fraudulentactivity is truly fraudulent, and/or classify fraudulent or suspectedfraudulent activity. For example, fraud detection/classification unit 36may analyze each transaction stored in account records database 30 todetermine whether that transaction is, or potentially is, fraudulent.Alternatively, fraud detection/classification unit 36 may analyze onlythose transactions that were flagged as possibly being fraudulent (e.g.,by a cardholder calling in to report an unauthorized and/or unrecognizedtransaction, or by FAMS 14 or AFSS 12 generating a preliminary fraudalert after applying an initial set of rules to a transaction, etc.).Fraud detection/classification unit 36 may also, or instead, analyzelocation information associated with potential transactions (e.g., GPSor other data indicating cardholder location, transaction dataindicating a merchant location for a card-present transaction, etc.),and issue a pre-transaction alert or otherwise prevent a transactionfrom being fully executed. Fraud detection/classification unit 36 mayalso, or instead, support additional functionality, such as thatdescribed below in connection with the various components of frauddetection/classification unit 36 shown in FIG. 1.

As seen in FIG. 1, fraud detection/classification unit 36 may include amachine learning (ML) rule generator 40, an external data collectionunit 42, a behavior analysis unit 44, a dispute resolution unit 46, achargeback analysis unit 50, an image analysis unit 52, a classificationunit 54, and/or a notification unit 56. In other embodiments, frauddetection/classification unit 36 may include more, fewer and/ordifferent components/units than those shown in FIG. 1. In someembodiments, each of ML rule generator 40, external data collection unit42, behavior analysis unit 44, dispute resolution unit 46, chargebackanalysis unit 50, image analysis unit 52, classification unit 54,notification unit 56, and/or other units or components of frauddetection/classification unit 36 may be a software component stored inmemory 34 and implemented by one or more processors of one or morecomputing devices (e.g., servers) included in AFSS 12.

ML rule generator 40 may generally analyze various types of data togenerate and/or update fraud detection and/or classification rules to beapplied by fraud detection/classification unit 36 and stored in an MLrules database 58. As discussed in further detail below, the rules maybe used to detect and/or classify a single type or category offraudulent activity, or may be used broadly in connection with multipletypes or categories of fraudulent activity. ML rule generator 40 mayimplement any suitable type or types of machine learning. For example,ML rule generator 40 may implement supervised learning techniques, suchas decision trees, regression-based models, support vector machines(SVMs) and/or neural networks, and/or unsupervised learning techniquessuch as Dirichlet process mixture models and/or k-means clustering.Other machine learning techniques are also possible, such as techniquesutilizing Bayesian networks, “deep learning” techniques, and so on.While shown in FIG. 1 as a single entity within AFSS 12, it isunderstood that ML rules database 58 may, in some embodiments, bedistributed across multiple databases and/or multiple physical/hardwarememories, and/or may be wholly or partially external to (e.g., remotefrom) AFSS 12.

External data collection unit 42 may generally collect, via networkinterface 32 and/or from sources internal to AFSS 12, information fromvarious sources (e.g., FAMS 14, cardholder computing devices 20, othersources 24, etc.), and provide that data to other portions of AFSS 12 asneeded (e.g., to ML rule generator 40 to generate and/or update rules,and/or to behavior analysis unit 44, dispute resolution unit 46,chargeback analysis unit 50, image analysis unit 52 and/orclassification unit 54 to detect and/or classify fraudulent activity).Some data may be collected indirectly. For example, FAMS 14 may collecttransaction data from merchant computing systems 22 (and/or fromacquiring banks associated with one or more of merchant computingsystems 22), and external data collection unit 42 may then collect thatdata from the account records database 30 of FAMS 14.

Once an initial set of rules has been generated and stored in ML rulesdatabase 58, those rules may dictate some or all of the types of datagathered by external data collection unit 42. In some embodiments,however, external data collection unit 42 collects a broad set of datatypes that may or may not be relevant to fraud determination orclassification, and ML rule generator 40 continually analyzes that datato determine which data types are most predictive of fraud and/or fraudtype/class.

Behavior analysis unit 44 may generally analyze cardholder-related (orother customer-related) information to identify patterns of behavior,which may then be used by fraud detection/classification unit 36 todetect and/or classify fraudulent activity. For example, behavioranalysis unit 44 may analyze information obtained from account recordsdatabase 30 to identify spending patterns associated with differentcardholders. The operation of behavior analysis unit 44, including thetypes of information analyzed and the ways in which that information isused to arrive at a result (e.g., a pattern of behavior), may bedictated by the rules stored in ML rules database 58.

Data indicative of the behavior patterns identified by behavior analysisunit 44 may be stored in an account holder behaviors database 60, forexample. While shown in FIG. 1 as a single entity within AFSS 12, it isunderstood that account holder behaviors database 60 may, in someembodiments, be distributed across multiple databases and/or multiplephysical/hardware memories, and/or may be wholly or partially externalto (e.g., remote from) AFSS 12. In one embodiment, for example, accountholder behaviors database 60 may be included within account recordsdatabase 30. In still other embodiments, the environment 10 may notinclude account holder behaviors database 60, and behavior patterns maybe only identified by behavior analysis unit 44 “on the fly” as neededby fraud detection/classification unit 36 (e.g., when needed to analyzea transaction in view of past spending patterns of a particularcardholder, etc.).

In some embodiments, behavior analysis unit 44 may separately analyzethe transactions associated with each account holder, even if more thanone account holder exists for a particular account. For example,behavior analysis unit 44 may independently analyze the transactions ofeach cardholder for a credit or debit card account in which each spousehas been issued a credit or debit card in his or her name. Frauddetection/classification unit 36 may then utilize the individualspending patterns when detecting and/or classifying fraud. In oneembodiment where fraud detection/classification unit 36 utilizes adollar amount threshold to detect likely fraudulent transactions, forexample, a first threshold may be used for transactions made by a firstcardholder listed on an account, and a higher, second threshold may beused for transactions made by a second cardholder listed on the account.Further examples are provided below in connection with FIG. 6, accordingto various embodiments. In this manner, fraud detection and/orclassification may be made more precise than would be the case ifspending patterns were only identified at the aggregate level (e.g.,using a single dollar amount threshold, regardless of which cardholdermade a particular transaction).

Dispute resolution unit 46 may generally analyze financial transactiondata and/or other information to automatically generate queries forcardholders or other customers. For example, dispute resolution unit 46may analyze information obtained from account records database 30. Thegenerated queries may be designed to help fraud detection/classificationunit 36 determine whether a particular transaction was fraudulent, orestimate a probability that the transaction was fraudulent, etc. Disputeresolution unit 46 may also process responses fromcardholders/customers, and automatically generate additional queriesbased upon those responses. Examples of the operation of disputeresolution unit 46 are provided below in connection with FIGS. 4E and 9,according to various embodiments.

Chargeback analysis unit 50 may generally analyze financial transactionand/or other information to identify transactions that are goodcandidates for chargeback payments. For example, chargeback analysisunit 50 may analyze information obtained from account records database30 to determine whether there is a relatively high probability that themerchant (or an acquiring bank) should be responsible for a chargebackpayment to a card issuer associated with FAMS 14. The operation ofchargeback analysis unit 50, including the types of information analyzedand the ways in which that information is used to arrive at a result(e.g., flagging a transaction as a chargeback candidate), may bedictated by the rules stored in ML rules database 58. ML rule generator40 may make use of chargeback rules obtained from a card network entity(e.g., from card network computing system 16), and stored in chargebackrules database 62, to generate and/or update the rules applied bychargeback analysis unit 50. Examples of the operation of chargebackanalysis unit 50 are provided below in connection with FIGS. 4B and 7,according to various embodiments.

In some embodiments, transactions flagged by chargeback analysis unit 50are subject to further, manual review using the chargeback rules storedin chargeback rules database 62. In other embodiments, chargebackanalysis unit 50 (or another component of fraud detection/classificationunit not shown in FIG. 1) automatically, with little or no manualinput/assistance, applies the chargeback rules from chargeback rulesdatabase 62 for each flagged transaction. While shown in FIG. 1 as asingle entity within AFSS 12, it is understood that chargeback rulesdatabase 62 may, in some embodiments, be distributed across multipledatabases and/or multiple physical/hardware memories, and/or may bewholly or partially external to (e.g., remote from) AFSS 12.

Image analysis unit 52 may generally analyze image data corresponding tophysical documents to identify fraudulent (e.g., counterfeit and/orforged) documents, and/or to flag potentially fraudulent documents forfurther (e.g., manual) review. For example, image analysis unit 52 mayanalyze information obtained from merchant computing systems 22 todetermine whether there is a relatively high probability that documentspresented to the merchants (e.g., personal checks, identification cards,etc.) are fraudulent. Image analysis unit 52 may be configured toanalyze only a single type of document, or multiple types of documents.The operation of image analysis unit 52, including the imagecharacteristics analyzed and the ways in which the characteristics maybe used to arrive at a result (e.g., flagging a document as potentiallyfraudulent), may be dictated by the rules stored in ML rules database58. Examples of the operation of image analysis unit 52 are providedbelow in connection with FIGS. 4F and 10, according to variousembodiments.

Classification unit 54 may generally analyze broad categories of datafrom various sources (e.g., account records database 30, cardholdercomputing devices 20, merchant computing systems 22, and/or othersources 24) to categorize/classify types of suspected fraudulentfinancial activity. Classification unit 54 may classify fraudulentactivity only within a particular subset of fraudulent financialactivity (e.g., classifying debit and/or credit card transactions asinvolving a potential case of counterfeiting, skimming, lost/stolen carduse, chargeback fraud, etc.), or may classify fraudulent financialactivity across a broader spectrum (e.g., including types of identitytheft not necessarily tied to a single financial transaction, such asapplication fraud). In some embodiments, classification unit 54classifies suspected fraudulent activity in connection with a particularaccount or transaction in response to being notified of suspect activity(e.g., notified by another component of fraud detection/classificationunit 36, or by a manual user input, etc.). In other embodiments,classification unit 54 itself (or another component of frauddetection/classification unit 36) identifies suspect activity beforeclassification unit 54 classifies that activity. Examples of theoperation of classification unit 54 are provided below in connectionwith FIGS. 4C and 11, according to various embodiments.

Notification unit 56 may generally provide alerts, confirmations, and/orother notifications to various individuals (e.g., customers, bankemployees associated with FAMS 14, third party employees associated withAFSS 12, etc.). For example, notification unit 56 may generate anotification message stating that a fraud alert associated with aparticular transaction is a false positive, and cause network interface32 to send the message to a computer terminal or to FAMS 14 for displayto a system user. As another example, notification unit 56 may causenetwork interface 32 to send other flagged transactions and/or documents(e.g., chargeback candidates identified by chargeback analysis unit 50,documents that image analysis unit 52 has identified as potentiallyfraudulent, etc.) to a computer terminal or FAMS 14 for display to asystem user. As still another example, notification unit 56 may causenetwork interface 32 to send FAMS 14 and/or one of merchant computingsystems 22 an alert indicating that a transaction that is in-processshould be terminated due to suspected fraud. As yet another example,notification unit 56 may cause network interface 32 to send queriesgenerated by dispute resolution unit 46 to various ones of cardholdercomputing devices 20 for display to cardholders.

The operation of various components of the environment 10 shown in FIG.1, according to different embodiments and/or scenarios, will bedescribed further below in connection with the remaining figures.

III. Exemplary Process Flows for Machine Learning of Fraud Detectionand/or Classification Rules

As discussed above, ML rule generator 40 may generate and/or updaterules that are used for one or more of a variety of different purposesrelating to fraud detection and/or classification. FIG. 2 depicts onegeneralized, example process flow 80 for machine learning that may beimplemented by ML rule generator 40, and possibly one or more othercomponents of fraud detection/classification unit 36.

In the process flow 80, multi-account data 82 may represent dataassociated with multiple financial accounts, each with one or moreaccount holders. The financial accounts may be existing or potentialaccounts, and the account holders may include holders of accounts and/orpotential holders of potential accounts. For example, the multi-accountdata 82 may include existing and/or applied-for credit card accounts,debit card accounts, savings accounts, checking accounts, investmentaccounts, loan accounts, etc.

Depending upon the embodiment, the multi-account data 82 may include oneor more different types of information obtained (e.g., by external datacollection unit 42 of FIG. 1) from one or more of FAMS 14, cardholdercomputing devices 20, merchant computing systems 22, and/or othersources 24. For example, the multi-account data 82 may includetransaction data (e.g., transaction dates, amounts, locations, etc.)from account records database 30 of FAMS 14, data indicative of InternetProtocol (IP) addresses of cardholder computing devices 20 and/ordevices in merchant computing systems 22, Internet browsing and/orsearch history data from cardholder computing devices 20 (or from an ISPcomputer system included in other sources 24, etc.), vehicle telematicsdata from telematics systems of cardholder vehicles, home occupancyand/or usage data (e.g., smart appliance data) from smart home systemsof cardholders, autonomous or smart vehicle data, vehicle navigationsystem data, mobile device data, mobile device and/or vehicle GPS data,and/or one or more other types of data. In some embodiments, themulti-account data 82 only includes data that account holders orpotential account holders have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forfraud protection services). In certain other embodiments, however,express consent is only needed for certain types of information, such asbrowsing history information, vehicle telematics data, etc.

The multi-account data 82 may be associated with multiple frauddetermination labels. The labels may simply reflect whether or not fraudexisted (e.g., “fraud” or “no fraud”), or may also indicate a type orclass of fraud (e.g., “counterfeiting,” “lost or stolen card use,”etc.), for example. In one embodiment, each of a number of data sets inthe multi-account data 82 is associated with such a label, and includesdata relating to a particular financial transaction, financial account,loan application, etc., for which the fraud determination was made(e.g., after a manual and/or automated fraud investigation). The labelsmay include final fraud determinations that were made via earlieriterations of the process flow 80, and/or external to the process flow80.

To provide a more detailed example, a first data set associated with a“card present” credit card transaction may include data describing thattransaction (e.g., from account records database 30) and data indicativeof the cardholder's online browsing activity (e.g., from one ofcardholder computing devices 20) for the 15 days immediately precedingthe transaction, and be labeled “confirmed fraud.” A second data set,associated with another “card present” transaction (for the sameaccount, or for a different account), may include the same general typesof data but be labeled “no fraud,” and so on. In some embodiments and/orscenarios, the same data may appear in, or be used by, two or more ofthe data sets. If the two “card present” transactions described aboveare both associated with the same account, for example, and if thesecond transaction occurred less than 15 days after the firsttransaction, some of the same online activity data may be shared by thefirst and second data sets.

At a process stage 84, the multi-account data 82 may be analyzed togenerate fraud detection and/or classification rules (e.g., to be storedin ML rules database 58). Any suitable type of supervised machinelearning program/technique(s) may be used, such as SVMs, neuralnetworks, logistic regression, etc. Generally, process stage 84 mayserve to identify which type(s) of data is/are probative of whetherfraud has occurred (and/or the type/category of fraud that may haveoccurred), and to determine the data values and/or combinations that areprobative of whether fraud has occurred (and/or the type/category offraud that may have occurred). By analyzing many (e.g., thousands) ofpositively and negatively labeled data sets in the multi-account data82, for example, process stage 84 may learn that certain spendingpatterns within a threshold time of a transaction tend to indicate thatthe cardholder made the transaction (e.g., thereby indicating that fraudhas not occurred, or that a fraud report is itself fraudulent ormistaken, etc.), that certain types of online searches by a cardholder(e.g., including a descriptor of a product purchased in the transaction,or a name of the merchant, etc.) tend to indicate that the cardholdermade the transaction, that the cardholder's distance from the site of a“card present” transaction (e.g., as determined from GPS informationprovided by the cardholder's smartphone, wearable electronics, orvehicle) relates to the probability of fraudulent activity according toa particular equation, and so on. Other specific examples of such rules,and how those rules may be generated, are discussed below in connectionwith FIGS. 3A-3F and 4A-4F, according to various embodiments.

At process stage 86, the rules generated or updated at process stage 84may be applied to first account data 90 associated with a particularaccount and customer(s) (e.g., a customer associated with a particularone of computing devices 20). The types of data included in firstaccount data 90 may depend upon which types of data were determined, byprocess stage 84, to be relevant to a fraud determination. For example,if the rules give weight to the amount and date of a financialtransaction when determining whether the transaction is fraudulent, andalso give weight to whether the account holder visits a particular typeof website, then the first account data 90 may include the amount anddate of one or more transactions, as well as data indicative of visitedweb sites (e.g., Uniform Resource Locators (URLs) and/or content ofvisited websites, etc.). The first account data 90 may includeinformation obtained (e.g., by external data collection unit 42) fromone or more of FAMS 14, one of cardholder computing devices 20associated with the customer holding the first account, one or more ofmerchant computing systems 22, and/or one or more of other sources 24,for example.

Process stage 86 may output various different types of information,depending upon the embodiment and/or scenario. For example, dependingupon the content of first account data 90 and the rules generated orupdated at process stage 84, process stage 86 may generate dataindicating that a particular financial transaction associated with firstaccount data 90 is, or is not, fraudulent or potentially fraudulent.Alternatively, or additionally, process stage 86 may generate dataindicating a particular classification for fraudulent or suspectedfraudulent activity (e.g., a fraudulent transaction) associated withfirst account data 90.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) may be performedat an additional stage, shown in dashed lines in FIG. 2 as process stage92. The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether fraud occurred, and/oron the type of fraud that occurred) at process stage 94. In otherembodiments, process stage 92 is omitted from process flow 80, andprocess stage 94 merely represents the output of process stage 86. Thefinal determination made at process stage 94, along with the firstaccount data 90 used to make that determination, may be fed back intoprocess stage 84 to provide additional labeled data for purposes ofupdating the rules.

In some embodiments, the process flow 80 includes more, fewer and/ordifferent stages, such as any of those discussed elsewhere herein (e.g.,in connection with FIGS. 3A-3F). In one alternative embodiment, processstages 84 and 86 may be combined. For example, the multi-account data 82may be unlabeled rather than labeled (or the labels may be ignored), andthe combined process stage 84, 86 may use unsupervised learningtechniques (e.g., clustering techniques) to classify anomalous/outlierfinancial transactions, accounts, applications, etc., as “suspect” andneeding further analysis.

More specific, machine learning-based process flows generallycorresponding to process flow 80 of FIG. 2 will now be described withreference to FIGS. 3A-3F. It is noted, however, that other process flowsare also within the scope of the invention described herein. Moreover,while FIGS. 3A-3F generally correspond to embodiments in whichsupervised machine learning techniques are used, other embodiments mayinstead use unsupervised machine learning techniques, as noted above. Invarious different embodiments, fraud detection/classification unit 36may be configured to implement only one of the process flows of FIGS.3A-3F, or may be configured to implement two or more (e.g., all) of theprocess flows shown in FIGS. 3A-3F.

A. Exemplary Process Flow for Machine Learning of Fraud Detection RulesUsing Online Activity Data

Referring first to FIG. 3A, an exemplary process flow 100 may generallybe used to detect fraud using customer online activity data. In theprocess flow 100, multi-customer online activity data 102 may representdata associated with the online activities of a number (e.g., thousands)of customers (e.g., credit or debit cardholders, checking or savingaccount holders, etc.). The multi-customer online activity data 102 mayinclude data indicating actions that the customers took, and/or websites visited by the customers, while the customers were connected tothe Internet via web browsers (e.g., executing on respective ones ofcardholder computing devices 20). For example, the multi-customer onlineactivity data 102 may include URLs of, and/or content (e.g., text)within, web sites visited by customers, search terms entered bycustomers using search engine tools, search results presented tocustomers by search engine tools, indications of interactive controls(e.g., virtual buttons) selected by customers on various web pages, andso on.

The multi-customer online activity data 102 may include data obtained(e.g., by external data collection unit 42 of FIG. 1) from cardholdercomputing devices 20, from one or more ISPs of other sources 24, and/orfrom a third party aggregator of such information, for example. In someembodiments, the multi-customer online activity data 102 may onlyinclude data that customers have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forfraud protection services or other benefits, such as discounts).

As described above in connection with multi-account data 82 of processflow 80, the multi-customer online account data 102 may be associatedwith multiple fraud determination labels. In some embodiments, eachlabel may be associated with a data set that includes not only thecorresponding portion of multi-customer online activity data 102, butalso one or more other types of data, such as transaction data (e.g.,transaction dates, amounts, locations, etc.) for each customer fromaccount records database 30 of FAMS 14, data indicative of IP addressesof cardholder computing devices 20 and/or devices in merchant computingsystems 22, Internet browsing and/or search history data from cardholdercomputing devices 20 (or from an ISP computer system included in othersources 24, etc.), vehicle telematics data from telematics systems ofother sources 24, home occupancy and/or usage data (e.g., smartappliance data) from smart home systems of other sources 24, and so on.The labels may include final fraud determinations that were made viaearlier iterations of the process flow 100, and/or external to theprocess flow 100. Multi-customer online account data 102 may includemany (e.g., thousands) of positively and negatively labeled data sets.

At a process stage 104, the multi-customer online activity data 102 maybe analyzed to generate fraud detection rules (e.g., to be stored in MLrules database 58). As described above in connection with process stage84 of process flow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 104 may serveto identify which type(s) of online activity data is/are probative ofwhether fraud has occurred, and to determine the data values and/orcombinations that are probative of whether fraud has occurred. While notshown in FIG. 3A, the fraud detection rules may not only detect fraud,but also classify fraud (e.g., as described below in connection withFIG. 3C), in some embodiments.

At process stage 106, the rules generated or updated at process stage104 may be applied to first customer online activity data 110. The firstcustomer online activity data 110 may be associated with a particularcustomer, such as a customer associated with a particular one ofcomputing devices 20, for example. The types of data included in firstcustomer online activity data 110 may depend upon which types of onlineactivity data were determined, by process stage 104, to be relevant to afraud determination. For example, the first customer online activitydata 110 may include information obtained (e.g., by external datacollection unit 42) from one of cardholder computing devices 20 (i.e.,the device associated with the first customer), and/or from an ISP ofother sources 24. Some specific examples of rules that may be generatedby process stage 104, and applied at process stage 106, are describedbelow in connection with FIG. 4A.

Process stage 106 may output various different types of information,depending upon the embodiment and/or scenario. For example, dependingupon the content of first customer online activity data 110 and therules, process stage 106 may generate data indicating that a particularfinancial transaction associated with the first customer is, or is not,fraudulent or potentially fraudulent. Alternatively, or additionally,process stage 106 may generate data indicating a particularclassification of fraudulent or potentially fraudulent activityassociated with first customer online activity data 110.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) is performed at anadditional stage, shown in dashed lines in FIG. 3A as process stage 112.The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether fraud occurred, and/oron the type of fraud that occurred) at process stage 114. In otherembodiments, process stage 112 is omitted from process flow 100, andprocess stage 114 merely represents the output of process stage 106.

The final determination made at process stage 114, along with the firstcustomer online activity data 110 (and any other data) used to make thatdetermination, may be fed back into process stage 104 to provideadditional labeled data for purposes of updating the rules. In someembodiments, a preliminary fraud determination made at process stage 106is also fed back into process stage 104, to allow the machine learningprogram to determine and improve upon past performance/accuracy.

B. Exemplary Process Flow for Machine Learning of Chargeback CandidateDetection Rules

Referring next to FIG. 3B, an exemplary process flow 120 may generallybe used to identify the financial transactions for which chargebacks(e.g., post-transaction payments from merchants, or acquiring/merchantbanks, back to the issuer to return proceeds from transactions) areappropriate. In the process flow 120, multi-account transaction data 122may represent data associated with the financial transactions involvingthe accounts of a number (e.g., thousands) of credit or debitcardholders. The multi-account transaction data 122 may includeinformation such as transaction dates, transaction amounts, merchantnames (and/or aliases) associated with the transaction, informationrelating to how the card information was collected by the merchant(e.g., by swiping, an EMV chip reader, manual entry of the card number,etc.), geographic locations of “card present” transactions, and so on.The multi-account transaction data 122 may include data obtained (e.g.,by external data collection unit 42 of FIG. 1) from merchant computingsystems 22 and/or from acquiring/merchant banks associated with thosemerchants, for example.

Similar to the labels described above in connection with multi-accountdata 82 of process flow 80, the multi-account transaction data 122 maybe associated with multiple chargeback outcome labels. For example, eachlabel may be associated with a data set that includes the correspondingportion of multi-account transaction data 122. The outcome labels mayinclude final chargeback determinations that were made (in connectionwith the transactions represented in multi-account transaction data 122)via earlier iterations of the process flow 120, and/or external to theprocess flow 120. Multi-account transaction data 122 may include many(e.g., thousands) of positively and negatively labeled data sets.

At a process stage 124, the multi-account transaction data 122 may beanalyzed to generate chargeback candidate detection rules (e.g., to bestored in ML rules database 58). As described above in connection withprocess stage 84 of process flow 80, any suitable type of supervisedmachine learning program/technique(s) may be used. Generally, processstage 124 may serve to identify which type(s) of transaction data is/areprobative of whether, under the full chargeback rules of the cardnetwork entity, a chargeback is appropriate for a given transaction.Process stage 124 may also determine the transaction data values and/orcombinations that are probative of whether a chargeback is appropriatefor the transaction.

At a process stage 126, the rules generated or updated at process stage124 may be applied to first account transaction data 130 to determinewhether a transaction associated with the first account is a “good”chargeback candidate. Put differently, process stage 126 may, instead ofapplying the full chargeback rules of the card network entity (which maybe quite lengthy and complex) to the facts surrounding the transaction,use various factors and algorithms developed at process stage 124 todetermine whether there exists a relatively high probability that achargeback would be appropriate for the transaction if the fullchargeback rules were applied. The process stage 126 may calculate apercentage probability that the transaction is one in which a chargebackis appropriate, for example.

The first account transaction data 130 may be associated with theaccount of a particular cardholder or cardholders, such as a cardholderassociated with a particular one of cardholder computing devices 20, forexample. The types of data included in first account transaction data130 may depend upon which types of transaction-related data weredetermined, by process stage 124, to be relevant to a chargebackcandidate determination. For example, the first account transaction data130 may include information obtained (e.g., by external data collectionunit 42) from one of merchant computing systems 22 (e.g., the computingsystem of the merchant involved in the transaction being analyzed)and/or from an acquiring/merchant bank associated with that merchant.The first account transaction data 130 may also include informationabout one or more other transactions associated with the first account(e.g., data pertaining to other transactions occurring shortly beforeand/or after the transaction at issue). Some specific examples of rulesthat may be generated by process stage 124, and applied at process stage126, are described below in connection with FIG. 4B.

Process stage 126 may output information indicating whether theparticular transaction represented by first account transaction data 130is a “good” candidate for chargeback detection. For example, processstage 126 may output a percentage probability, calculated according tothe rules generated or updated at process stage 124, that thetransaction is one in which a chargeback is appropriate. As anotherexample, process stage 126 may output a binary indicator of whether thetransaction is, or is not, a strong/likely chargeback candidate (e.g.,by comparing the percentage probability to a threshold probability).

If the transaction is identified as a chargeback candidate at processstage 126, the full chargeback rules of the card network entity may beapplied at a process stage 132. Process stage 132 may include manualapplication of the full chargeback rules, and/or automated applicationof the full chargeback rules, in various different embodiments. Basedupon the analysis at process stage 132, a final chargeback determinationmay be made at a process stage 134. The final determination made atprocess stage 134, along with the first account transaction data 130(and any other data) used to make that determination, may be fed backinto process stage 124 to provide additional labeled data for purposesof updating the rules. In some embodiments, the indication of whetherthe transaction is a good chargeback candidate generated at processstage 126 may also be fed back into process stage 124, to allow themachine learning program to determine and improve upon pastperformance/accuracy.

C. Exemplary Process Flow for Machine Learning of Fraud ClassificationRules

Referring now to FIG. 3C, an exemplary process flow 140 may generally beused to classify instances of suspected or potential fraud. For example,the process flow 140 may represent ongoing, real-time or batchprocessing of a large amount of data associated with a large number ofpotential and/or existing financial accounts (e.g., all accountsassociated with a particular bank, or all accounts opting in to a fraudprotection program, etc.). In this manner, the process flow 140 may beused to initially flag situations for closer investigation, and provideone or more classifications of the type(s) of fraud potentially at issuein order to narrow or otherwise facilitate the investigation. In otherembodiments, the process flow 140 may be used to provide a narrowerclassification (e.g., “skimming”) when a broader class of fraud (e.g.,credit card fraud) is already suspected.

In the process flow 140, multi-account data 142 may represent dataassociated with financial accounts of a number (e.g., thousands) ofaccount holders. The financial accounts may be existing or potentialaccounts, and the account holders may include holders of accounts and/orpotential holders of potential accounts. For example, the multi-accountdata 142 may include existing and/or applied-for credit card accounts,debit card accounts, savings accounts, checking accounts, investmentaccounts, loan accounts, etc.

Depending upon the embodiment, the multi-account data 142 may includeone or more different types of information obtained (e.g., by externaldata collection unit 42 of FIG. 1) from one or more of FAMS 14,cardholder computing devices 20, merchant computing systems 22, and/orother sources 24. For example, the multi-account data 142 may includetransaction data (e.g., transaction dates, amounts, locations, etc.)from account records database 30 of FAMS 14, data indicative of IPaddresses of cardholder computing devices 20 and/or devices in merchantcomputing systems 22, Internet browsing and/or search history data fromcardholder computing devices 20 (or from an ISP computer system includedin other sources 24, etc.), vehicle telematics data from telematicssystems of cardholder vehicles, home occupancy and/or usage data (e.g.,smart appliance data) from smart home systems of cardholders, and/or oneor more other types of data. Some or all data within multi-account data142 may be information that account holders or potential account holdershave expressly consented to share with an entity associated with FAMS 14and/or AFSS 12 (e.g., in exchange for fraud protection services).

The multi-account data 142 may be associated with multiple frauddetermination labels, each indicating a type or class of fraud (e.g.,“counterfeiting,” “lost or stolen card use,” “skimming,” “chargebackfraud,” “application fraud,” etc.), or indicating a lack of fraud, forexample. In one embodiment, each of a number of data sets in themulti-account data 142 is associated with at least one suchclassification/label, and includes data relating to a particularfinancial transaction, financial account, loan application, etc., forwhich the fraud classification or classifications was/were made (e.g.,after a previous iteration of process flow 140, or after another manualand/or automated fraud investigation). Multi-account data 142 mayinclude many (e.g., thousands) of data sets labeled with various knownfraud classifications.

At a process stage 144, the multi-account data 142 may be analyzed togenerate fraud classification rules (e.g., to be stored in ML rulesdatabase 58). As described above in connection with process stage 84 ofprocess flow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 144 may serveto identify which type(s) of transaction data is/are probative of theparticular type of fraud (if any) that has occurred. Process stage 144may also determine the data values and/or combinations that areprobative of the particular type of fraud (if any) that has occurred.

At a process stage 146, the rules generated or updated at process stage144 may be applied to first account data 150. The first account data 150may be associated with a particular account and a particular customer(e.g., a cardholder associated with a particular one of computingdevices 20). The types of data included in first account data 150 maydepend upon which types of data were determined, by process stage 144,to be relevant to fraud classification. For example, the first accountdata 150 may include information obtained (e.g., by external datacollection unit 42) from one or more of FAMS 14, one of cardholdercomputing devices 20 (i.e., the device associated with the customerholding or applying for the first account), one or more of merchantcomputing systems 22, and/or one or more of other sources 24. Somespecific examples of rules that may be generated by process stage 144,and applied at process stage 146, are described below in connection withFIG. 4C.

Process stage 146 may output data (e.g., a message or code) that is usedto classify suspected fraudulent activity (in connection with theaccount associated with first account data 150) at a process stage 152.For example, process stage 152 may assign a classification of“counterfeiting” if process stage 146 determined that the first accountdata 150 indicated a number of circumstances that, according to therules generated at process stage 144, are known to be correlated withcounterfeiting activity (e.g., two “card present” transactions occurringin different states within the same one-hour time period, etc.). In someembodiments and/or scenarios, two or more classifications mayconcurrently be assigned to first account data 150. For example, processstage 146 may determine a set of probabilities for a set of two or morepotential types of fraud, and process stage 152 may assign eachclassification, with each respective probability, to first account data150. Moreover, in some embodiments and scenarios, process stage 152 mayassign a classification that corresponds to an absence of any suspectedfraud (e.g., “no fraud”).

At a process stage 154, if process stage 152 assigned a classificationother than one indicating the absence of suspected fraud, the firstaccount data 150, and/or other information associated with the accountand the suspected class of fraud, may be analyzed in depth to make afinal fraud determination at a process stage 156. Generally, the fraudclassification may be used to facilitate the analysis at process stage154, with process stage 154 including manual and/or automated frauddetection techniques. For example, personnel associated with AFSS 12 mayuse the fraud classification(s) to inform their strategy and/or focuswith respect to conducting an in-depth fraud investigation.

The additional analysis at process stage 154 may then result in a finalfraud determination at process stage 156. The final determination mayindicate both whether fraud occurred and, if so, the class(es)/type(s)of fraud that occurred. The final determination made at process stage156, and information used to make that determination (e.g., the firstaccount data 150 and potentially other data), may be fed back intoprocess stage 144 to provide additional labeled data for purposes ofupdating the rules. In some embodiments, the (preliminary) fraudclassification made at process stage 152 may also be fed back intoprocess stage 144 to help the machine learning program identifyinstances in which the preliminary classifications at process stage 152were incorrect. Process stage 144 may then update the fraudclassification rules in ways that seek to prevent or reduce suchinstances in the future.

D. Exemplary Process Flow for Machine Learning of Application FraudDetection Rules

Referring now to FIG. 3D, an exemplary process flow 160 may generally beused to detect application fraud. “Application fraud” may generallyrefer to fraud in connection with the application for any type offinancial account, loan and/or line of credit (e.g., mortgage loan,vehicle loan, small business loan, payday loan, home equity line ofcredit, credit card account, debit card account, checking account,savings account, investment account, etc.). In some embodiments and/orscenarios, however, the application may be for non-financial purposes,such as an application for membership in a particular group orinstitution, for example.

In the process flow 160, multi-applicant search history data 162 mayrepresent data associated with the Internet search history of a number(e.g., thousands) of applicants. The multi-applicant search history data162 may include search terms entered by the applicants using onlinesearch engine tools, for example, and/or the results of such searches(e.g., URLs, titles and/or contents of search results), for example.

The multi-applicant search history data 162 may include data obtained(e.g., by external data collection unit 42 of FIG. 1) from cardholdercomputing devices 20, from one or more ISPs of other sources 24, and/orfrom a third party aggregator of such information, for example. In someembodiments, the multi-applicant search history data 162 only includesdata that the applicants have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forconsideration of their applications).

As described above in connection with multi-account data 82 of processflow 80, the multi-applicant search history data 162 may be associatedwith multiple fraud determination labels. In some embodiments, eachlabel may be associated with a data set that corresponds to anapplication submitted by a particular applicant, where the data setincludes the corresponding portion of multi-applicant search historydata 162 (e.g., the search terms and/or results associated with theparticular application). The labels may include final frauddeterminations that were made via earlier iterations of the process flow160, and/or external to the process flow 160. Multi-applicant searchhistory data 162 may include many (e.g., thousands) of positively andnegatively labeled data sets.

At a process stage 164, the multi-applicant search history data 162 maybe analyzed to generate application fraud detection rules (e.g., to bestored in ML rules database 58). As described above in connection withprocess stage 84 of process flow 80, any suitable type of supervisedmachine learning program/technique(s) may be used. Generally, processstage 164 may serve to identify which type(s) of Internet search-relateddata is/are probative of whether application fraud has occurred, and todetermine the data values and/or combinations that are probative ofwhether application fraud has occurred.

At process stage 166, the rules generated or updated at process stage164 may be applied to first applicant search history data 170. The firstapplicant search history data 170 may be associated with a particularapplication and a particular applicant (e.g., a person associated with aparticular one of computing devices 20), for example. The types of dataincluded in first applicant search history data 170 may depend uponwhich types of Internet search-related data were determined, by processstage 164, to be relevant to a fraud determination. The first applicantsearch history data 170 may include information obtained (e.g., byexternal data collection unit 42) from one of computing devices 20(i.e., the device associated with the first applicant), and/or from anISP of other sources 24, for example. Some specific examples of rulesthat may be generated by process stage 164, and applied at process stage166, are described below in connection with FIG. 4D.

Process stage 166 may output information indicating whether fraud issuspected in connection with the application corresponding to firstapplicant search history data 170. For example, process stage 166 mayoutput a percentage probability, calculated according to the rulesgenerated or updated at process stage 164, that the application wasfraudulently made (e.g., by someone other than the purported applicantor an authorized representative thereof). As another example, processstage 166 may output a binary indicator of whether the applicationlikely was, or likely was not, fraudulently made (e.g., by comparing apercentage probability to a threshold probability).

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) is performed at anadditional stage, shown in dashed lines in FIG. 3D as process stage 172.The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether application fraudoccurred) at process stage 174. In other embodiments, process stage 172is omitted from process flow 160, and process stage 174 merelyrepresents the output of process stage 166. The final determination madeat process stage 174, along with the first applicant search history data170 (and any other data) used to make that determination, may be fedback into process stage 164 to provide additional labeled data forpurposes of updating the rules. In some embodiments, a preliminary frauddetermination made at process stage 166 is also fed back into processstage 164, to allow the machine learning program to determine andimprove upon past performance/accuracy.

E. Exemplary Process Flow for Machine Learning of Fraud DisputeResolution Rules

Referring now to FIG. 3E, an exemplary process flow 180 may generally beused to facilitate the resolution of fraud disputes (or potentialdisputes) with customers/account holders. For example, the process flow180 may be used to determine whether a reportedly unauthorized orfraudulent transaction (e.g., one that the account holder reported assuch when looking at his or her account statement) was indeedunauthorized or fraudulent. In some embodiments, the process flow 180may also, or instead, be used to determine whether an “unrecognized”transaction (i.e., one that the account holder does not recall, but doesnot necessarily report as fraudulent) was unauthorized or fraudulent.

In the process flow 180, multi-account data 182 may represent dataassociated with financial accounts of a number (e.g., thousands) ofaccount holders. For example, the multi-account data 182 may includedata associated with financial transactions relating to credit cardaccounts, debit card accounts, savings accounts, checking accounts, etc.For ease of explanation, FIG. 3E will be described with reference to anembodiment in which the accounts are credit card accounts.

In one embodiment, the multi-account data 182 may include transactiondata (e.g., transaction dates, amounts, locations, etc.) obtained fromFAMS 14 (e.g., by external data collection unit 42 of FIG. 1). In someembodiments, however, the multi-account data 182 also includesinformation obtained from cardholder computing devices 20, merchantcomputing systems 22, and/or other sources 24. For example, themulti-account data 182 may include, in addition to transaction data fromaccount records database 30 of FAMS 14, data indicative of IP addressesof cardholder computing devices 20 and/or devices in merchant computingsystems 22, Internet browsing and/or search history data from cardholdercomputing devices 20 (or from an ISP computer system included in othersources 24, etc.), vehicle telematics data from telematics systems ofcardholder vehicles, home occupancy and/or usage data (e.g., smartappliance data) from smart home systems of cardholders, autonomousvehicle data, smart vehicle data, mobile device data, vehicle or mobiledevice GPS data, and/or one or more other types of data. Some or alldata within multi-account data 182 may be information that accountholders or potential account holders have expressly consented to sharewith an entity associated with FAMS 14 and/or AFSS 12 (e.g., in exchangefor fraud protection services).

As described above in connection with multi-account data 82 of processflow 80, the multi-account data 182 may be associated with multiplefraud determination labels (e.g., “fraud” and “no fraud,” and/or morecomplex labels that indicate type/class, such as “lost/stolen card use,”etc.). In some embodiments, each label may be associated with a data setthat includes the corresponding portion of multi-account data 182. Thelabels may include final fraud determinations that were made via earlieriterations of the process flow 180, and/or external to the process flow180. Multi-account data 182 may include many (e.g., thousands) ofpositively and negatively labeled data sets.

At a process stage 184, the multi-account data 182 may be analyzed togenerate query generation rules (e.g., to be stored in ML rules database58). As described above in connection with process stage 84 of processflow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 184 may serveto identify which types of information are probative of whether fraudhas occurred, and to craft rules that formulate queries to ascertainsuch information based upon account data.

For example, process stage 184 may determine that, for a suspect “cardpresent” transaction, a verified, non-fraudulent “card present”transaction within 10 miles and 3 hours of the suspect transaction isprobative of whether the suspect transaction was fraudulent. Based uponthis finding, process stage 184 may also generate a rule specifying thata cardholder should be queried as to whether he/she can confirm makingeach “card present” transaction within 10 miles and 3 hours of thesuspect transaction. As another example, process stage 184 may determinethat a merchant using a billing alias different from its legal and/orcommonly-known name (e.g., by at least some threshold level ofsimilarity, as measured by number of similar characters, order ofcharacters, etc.) is probative of whether the cardholder authorized atransaction associated with that billing alias. Based upon this finding,process stage 184 may generate a rule specifying that a cardholdershould be queried as to whether he/she is aware of a billing alias usedfor a suspect transaction if that billing alias is sufficientlydifferent from the legal/common name of the merchant.

At process stage 186, the rules generated or updated at process stage184 may be applied to first account data 190. The first account data 190may be associated with a particular cardholder, such as a cardholderassociated with a particular one of cardholder computing devices 20, forexample. The types of data included in first account data 190 may dependupon which types of data were determined, by process stage 184, to berelevant to developing dispute resolution queries. Process stage 186 maygenerate a set of one or more queries in accordance with the rules andthe contents of first account data. Some specific examples of rules thatmay be generated by process stage 184 and applied at process stage 186,and the queries that may be generated as a result, are described belowin connection with FIG. 4E.

At a process stage 192, the generated queries may be sent to thecardholder in one or more of various ways, such as sending the queriesvia SMS text message and/or email, and/or via a web browser or dedicatedapplication executing on the one of cardholder computing devices 20 thatis associated with the cardholder, for example. At a process stage 194,responses to the queries are received from the cardholder (e.g., viainputs made by the cardholder via the web browser or application, or aresponsive SMS text message or email, etc.). In some embodiments, therules generated or updated at process stage 184 specify the manner inwhich follow-up queries should be generated based upon the responsesreceived at process stage 194, and process stages 192 and 194 may berepeated multiple times.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) that makes use ofthe received responses is performed at an additional stage, shown indashed lines in FIG. 3E as process stage 196. The additional analysismay then be used to make a final fraud determination (e.g., a finaldecision on whether fraud occurred, and/or on the type of fraud thatoccurred) at process stage 198. In other embodiments, process stage 196is omitted from process flow 180, and process stage 198 is based uponinformation from the cardholder. For example, the questions generated atprocess stage 192 may “jog” the cardholder's memory, and cause him orher to indicate that the transaction at issue was authorized. The finaldetermination made at process stage 198, along with the first accountdata 110 (and any other data used at process stage 196), the queriesgenerated at process stage 186 and/or the responses received at processstage 194, may be fed back into process stage 184 to provide additionallabeled data for purposes of updating the rules.

F. Exemplary Process Flow for Machine Learning of Document FraudDetection Rules

Referring now to FIG. 3F, an exemplary process flow 200 may generally beused to detect fraud relating to documents, such as counterfeit and/orforged documents. The process flow 200 may be used in connection withvarious kinds of documents, such as checks (e.g., personal checks,cashier's checks, etc.), money orders, treasury bills, identificationdocuments (e.g., social security cards, driver's licenses, passports,birth certificates, etc.), certification documents, and so on.

In the process flow 200, multi-document image data 202 may representdigital images of a number (e.g., thousands) of physical documents ofone or more types. The multi-document image data 202 may include imagesin one or more formats, such as raster formats (e.g., JPEG, TIFF, GIF,BMP, PNG, etc.) and/or vector formats (e.g., CGM, SVG, etc.), forexample. The multi-document image data 202 may include data obtained(e.g., by external data collection unit 42 of FIG. 1) from merchantcomputing systems 22 (e.g., point-of-sale devices with cameras fordocument identification) and/or from FAMS 14 (e.g., images of personalchecks), for example. In some embodiments, the multi-document image data202 may only include data representing images that customers (or otherindividuals associated with the documents) have expressly consented toshare (e.g., as a prerequisite to making a purchase, or in exchange forfraud protection services, etc.).

As described above in connection with multi-account data 82 of processflow 80, the multi-document image data 202 may be associated withmultiple fraud determination labels. In some embodiments, each label maybe associated with data representing a digital image of a particulardocument. The labels may include final fraud determinations (e.g.,“fraud” or “no fraud,” or more complex labels such as “forgery,”“counterfeit,” “forgery—signature,” “counterfeit—angular line offset(s)outside tolerance,” etc.) that were made via earlier iterations of theprocess flow 200, and/or external to the process flow 200.Multi-document image data 202 may include many (e.g., thousands) ofpositively and negatively labeled data sets.

At a process stage 204, the multi-document image data 202 may beanalyzed to generate document fraud detection rules (e.g., to be storedin ML rules database 58). As described above in connection with processstage 84 of process flow 80, any suitable type of supervised machinelearning program/technique(s) may be used. Generally, process stage 204may serve to identify which characteristics of a document are probativeof whether the document is counterfeit, and to determine the ranges,tolerances, etc., that are probative of whether the document iscounterfeit. In some embodiments, process stage 204 also, or instead,identifies which characteristics of information entered in documentfields are probative of whether the document was forged (e.g., draftedor populated by someone other than the person purported to have draftedor populated the document).

At process stage 206, the rules generated or updated at process stage204 may be applied to first document image data 210. The first documentimage data 210 may be digital image data corresponding to a particular,physical document. The first document image data 210 may includeinformation obtained (e.g., by external data collection unit 42) fromone of merchant computing systems 22 (e.g., for real-time verificationof an identification or other document presented during or prior to asale), or from FAMS 14 (e.g., for real-time or batch-processingverification of a personal check prior to clearing the check), forexample. Some specific examples of rules that may be generated byprocess stage 204, and applied at process stage 206, are described belowin connection with FIG. 4F.

Process stage 206 may output information indicating whether fraud issuspected in connection with the document corresponding to firstdocument image data 210. For example, process stage 206 may output twopercentage probabilities calculated according to the rules generated orupdated at process stage 204, with the first indicating the likelihoodthat the document is counterfeit and the second indicating thelikelihood that the document includes forged content. As anotherexample, process stage 206 may output binary indicators of whether thedocument likely is, or likely is not, counterfeit and/or includes forgedcontent (e.g., by comparing percentage probabilities to thresholdprobabilities).

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) may be performedat a process stage 212. The additional analysis may then be used to makea final fraud determination (e.g., a final decision on whether thedocument is fraudulent) at process stage 214. For example, the processstage 206 may act as a filter, and flag only those documents having arelatively high probability of being fraudulent. In this manner, aconsiderably smaller amount of human and/or processing resources may beconsumed at process stage 212.

The final determination made at process stage 214, along with the firstdocument image data 210 used to make that determination, may be fed backinto process stage 204 to provide additional labeled data for purposesof updating the rules. In some embodiments, a preliminary frauddetermination made at process stage 206 may also be fed back intoprocess stage 204, to allow the machine learning program to determineand improve upon past performance/accuracy.

IV. Exemplary Rules for Fraud Detection and/or Classification

FIGS. 4A-4F depict exemplary factors and algorithms that may be used inconnection with various fraud detection and/or classification rules,according to different embodiments. It is noted that the rule setscorresponding to FIGS. 4A-4F are purely for purposes of illustration andare not limiting. Particularly in embodiments where machine learning isutilized, for example, the algorithms and/or factors may be far morecomplex, and/or less intuitive, than some or all of the examples shownin FIGS. 4A-4F.

A. Exemplary Fraud Detection Rule Set Using Online Activity

Referring first to FIG. 4A, an exemplary rule set 220 (e.g., generatedat process stage 104 of FIG. 3A) may use various factors relating toonline activity of a cardholder to detect fraud in connection with aparticular credit or debit card transaction. The rule set 220 maycorrespond to a particular embodiment and scenario in which thetransaction at issue is a “card present” transaction, and in which therule set 220 seeks to determine whether the cardholder made or otherwiseauthorized the transaction. The rule set 220 may be incorporated into areview process that is generally applied to all transactions, a reviewprocess applied only to those transactions that were flagged by apreliminary fraud alert, or a review process applied only after acardholder reports the transaction as unauthorized, for example.

The factors considered under the rule set 220 may include a number ofinterest-based factors 222 and a number of location-based factors 224.The interest-based factors 222 may relate to the cardholder's interest(or non-interest) in a product or service purchased via the transaction,and/or the merchant providing the product or service, while thelocation-based factors 224 may relate to the cardholder's location orprobable location.

As seen in FIG. 4A, the interest-based factors 222 may include: (1)whether the cardholder searched online for the specific product orservice purchased via the transaction at issue (e.g., by determiningwhether search terms entered by the cardholder included the name of theproduct or service involved in the transaction, or included adescription of the product or service, etc.); (2) whether the cardholdervisited a website associated with the merchant (e.g., by comparing URLsof web sites visited by the cardholder to a known URL of the merchant'swebsite, or by searching the contents of websites visited by thecardholder for the merchant's name, etc.); (3) whether the cardholderendorsed the merchant, or the product or service provided by themerchant, via a social media account of the cardholder (e.g., bydetermining whether the cardholder “liked” the merchant, product orservice via his or her Facebook® account, etc.); (4) whether thecardholder visited a website associated with a competitor of themerchant (e.g., by comparing URLs of web sites visited by the cardholderto known URLs of known competitors' websites, or by searching thecontents of websites visited by the cardholder for the competitors'names, etc.); (5) whether the cardholder searched online for a differentproduct or service in the same price range as the transaction amount(e.g., by analyzing search terms and/or results, and/or by analyzingURLs or contents of websites visited by the cardholder and comparingprices of products/services, etc.); and/or (6) whether the cardholderentered search terms indicative of the cardholder's need for the productor service (e.g., by determining that the cardholder entered searchterms including “pipe leak” prior to the purchase of new plumbinghardware, or “computer repair” prior to the purchase of a new harddrive, etc.). In other embodiments, the interest-based factors 222 mayinclude more, fewer and/or different factors than those shown in FIG.4A.

As is also seen in FIG. 4A, the location-based factors 224 may include:(1) whether the cardholder “checked in” to a flight having a destinationnear the location where the transaction was initiated (e.g., bydetermining whether the cardholder checked in to a flight having adestination at the city in which the transaction occurred, or within athreshold number of miles of the city in which the transaction occurred,etc.); (2) whether the cardholder visited a website associated with aplace near (or in) which the transaction was initiated (e.g., bycomparing URLs of web sites visited by the cardholder to URLs ofwebsites known to be associated with particular areas, and/or bysearching the contents of websites visited by the cardholder forlocation or area names, etc.); and/or (3) whether the cardholderendorsed a place near (or in) which the transaction was initiated via asocial media account of the cardholder (e.g., by determining whether thecardholder “liked” the geographic area, attraction or other place viahis or her Facebook® account, etc.). In other embodiments, thelocation-based factors 224 may include more, fewer and/or differentfactors than those shown in FIG. 4A.

Generally, the data indicative of whether the circumstance correspondingto each of interest-based factors 222 and/or location-based factors 224is present/true for a particular cardholder may be included in the firstcustomer online activity data 110 described above in connection withFIG. 3A. For example, external data collection unit 42 of FIG. 1 mayobtain the search terms, URLs, user online selections, etc., needed todetermine whether the various factors exist, from the cardholder'scomputing device (e.g., one of cardholder computing devices 20) and/orfrom an ISP of other sources 24.

As is also seen in FIG. 4A, each of the interest-based factors 222 andlocation-based factors 224 may be associated with a particular score orweighting value. In the rule set 220 shown in FIG. 4A, a total score maybe calculated based upon which factors are, or are not, present (e.g.,add 94 points if it is determined that the cardholder searched for theparticular lawnmower model that was purchased, add another 80 points ifthe transaction was a “card present” transaction in the Chicago suburbof Joliet and the cardholder checked in to a flight to Chicago justprior to the transaction, etc.).

In some embodiments, certain factors may instead be associated withnegative scores (e.g., minus 80 if the cardholder checked in to a flightwith a destination at least 200 miles from the site of the transactionand within one day of the transaction, etc.). Moreover, certain factorsmay be associated with metrics or algorithms that determine how heavilythose factors are weighed. As indicated in FIG. 4A, for example, searchterms entered by the cardholder may be used to calculate a “need score”X (e.g., where X is based upon frequency of certain search terms beingused, the amount of time spent clicking through search results, themagnitude and/or urgency of a problem indicated by the search terms,etc.), with X then being used to calculate a score equal to 0.2×.

The rule set 220 may then output the total score (e.g., 94+80=+174), anormalized total score, an indication of whether the total scoreexceeded a threshold (e.g., a threshold of +100), a probabilitycalculated based upon the total score, and/or some other indicator ormeasure of the existence or likelihood of fraud. In the example shown inFIG. 4A, it can be seen that larger scores generally correspond to agreater probability that the transaction was made or authorized by thecardholder. If the transaction is being automatically reviewed (e.g., todetermine whether a fraud alert is appropriate, without any initialinput from the cardholder), this may mean that a lower score correspondsto a higher probability of fraud. Conversely, if the cardholder hadreported the transaction as being fraudulent, a higher score maycorrespond to a higher probability of fraud (i.e., fraud on the part ofthe cardholder).

In some embodiments, the rule set 220 may also include one or more othertypes of factors not necessarily based upon online activities of thecardholder (e.g., whether GPS of the cardholder's smartphone or vehicleindicates that he or she was in that area shortly before or after thetransaction, etc.), and/or may omit either interest-based factors 222 orlocation-based factors 224.

B. Exemplary Chargeback Candidate Detection Rule Set

Referring next to FIG. 4B, an exemplary rule set 230 (e.g., generated atprocess stage 124 of FIG. 3B) may use various factors relating to atransaction between a cardholder and a merchant to determine whether thetransaction should be flagged as a candidate for a chargeback (e.g., todetermine whether the transaction should be reviewed under a full set ofchargeback rules associated with the appropriate card network entity).The rule set 230 may correspond to a particular embodiment and scenarioin which the transaction at issue is a “card present” transaction.

As seen in FIG. 4B, the factors considered under the rule set 230 mayinclude: (1) whether an EMV chip card was not inserted in apoint-of-sale EMV chip reader device of the merchant; (2) whether anon-EMV card was not swiped in a point-of-sale device of the merchant;(3) whether the card is past its expiration date; (4) whether thetransaction is for the same amount and/or date as another transactioninvolving the same card and merchant (e.g., by analyzing othertransactions involving the same account and merchant within a particulartime span); and/or (2) whether the transaction is for greater than athreshold amount. For example, one of merchant computing systems 22 ofFIG. 1 (or an acquiring/merchant bank) may provide transaction detailsthat include the amounts, dates, etc., to FAMS 14 for storage in accountrecords database 30, and external data collection unit 42 may thenretrieve that information from account records database 30. Generally,the data indicative of whether the circumstance corresponding to each ofthe factors is present/true for a particular transaction may be includedin the first account transaction data 130 described above in connectionwith FIG. 3B. In other embodiments, the factors considered under ruleset 230 may include more, fewer and/or different factors than thoseshown in FIG. 4B. It is noted that, in some embodiments, one or morefactors may simply relate to the desirability (e.g., from a card issuerperspective) of further reviewing whether a chargeback is appropriate,without necessarily relating to the likelihood that a chargeback isappropriate.

As is also seen in FIG. 4B, each of the factors may be associated with aparticular score or weighting value. A total score may be calculatedbased upon which factors are, or are not, present (e.g., add 62 pointsif it is determined that the transaction has the same amount and date asanother transaction occurring close in time and involving the same cardand merchant). In some embodiments, certain factors may instead beassociated with negative scores, and/or certain factors may beassociated with metrics or algorithms that determine how heavily thosefactors are weighed.

The rule set 230 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the likelihood that a chargeback is appropriatefor the transaction. In the example shown in FIG. 4B, it can be seenthat larger scores generally correspond to a greater probability that achargeback is appropriate.

C. Exemplary Fraud Classification Rule Set

Referring now to FIG. 4C, an exemplary rule set 240 (e.g., generated atprocess stage 144 of FIG. 3C) may use a diverse array of factors toclassify the type(s) of fraudulent activity, if any, that is/aresuspected to be associated with an event or series of events. The ruleset 240 may correspond to a particular embodiment and scenario in whichthe event at issue is a financial transaction involving a debit orcredit card. In other embodiments and/or scenarios, however, the ruleset 240 may classify fraudulent activity with respect to specific othertypes of events (e.g., loan applications), or may detect a variety ofdifferent event types (e.g., various types of financial transactions,loan or credit applications, etc.) and broadly classify fraudulentactivity in connection with the detected event types (e.g., lost/stolencard use, application fraud, etc.).

In one embodiment, each potential classification (with the possibleexception of “no fraud”) may be associated with a number of factorsprobative of whether that type/class of fraud has occurred. As seen inFIG. 4C, for example, the rule set 240 may include counterfeit factors242 (e.g., factors indicating that a counterfeit card was used for thetransaction), account takeover factors 244 (e.g., factors indicatingthat the transaction resulted from an unauthorized person gaining onlineaccess to the credit or debit card account itself, via phishing, malwareor other means), chargeback fraud factors 246 (e.g., factors indicatingthat the cardholder made or otherwise authorized a purchase that thecardholder later contested) and skimming factors 248 (e.g., factorsindicating that the card information used for the transaction wasobtained via a skimming card reader device illegally installed in anATM, gas station pump or other location). In other embodiments, the ruleset 240 may also, or instead, include factors corresponding to one ormore other fraud classifications (e.g., forgery, lost/stolen card use,etc.).

As seen in FIG. 4C, the counterfeit factors 242 may include: (1) whetherthe suspect transaction and another, contemporaneous transaction (e.g.,occurring within one hour, etc.) in another state are both “cardpresent” transactions; and/or (2) if the suspect transaction is a “cardpresent” transaction, whether the card (if an EMV chip card) was notinserted in an EMV chip card reader. For example, one or more ofmerchant computing systems 22 of FIG. 1 (or one or moreacquiring/merchant banks) may provide transaction details that includewhether the transaction was “card present,” whether the card wasinserted in an EMV chip card reader, etc., to FAMS 14 for storage inaccount records database 30, and external data collection unit 42 maythen retrieve that information from account records database 30. Inother embodiments, the counterfeit factors 242 may include more, fewerand/or different factors than those shown in FIG. 4C.

The account takeover factors 244 may include: (1) whether the debit orcredit card account password was changed within the 10 days prior to thetransaction; and/or (2) whether the transaction was originated from anIP address not associated with the cardholder. For example, externaldata collection unit 42 may retrieve password change information fromaccount records database 30 of FIG. 1, which may log all password updateactivity, and/or may retrieve IP address information from one ofmerchant computing systems 22 (e.g., the computing system of themerchant involved in the transaction). In other embodiments, the accounttakeover factors 244 may include more, fewer and/or different factorsthan those shown in FIG. 4C.

The chargeback fraud factors 246 may include: (1) whether the cardholderhad searched online for the product or service purchased via thetransaction; and/or (2) whether the cardholder had visited a websiteassociated with the merchant involved in the transaction. For example,external data collection unit 42 of FIG. 1 may retrieve online searchinformation (e.g., search terms and/or results) and/or URLs from the oneof cardholder computing devices 20 that is associated with thecardholder, and/or from an ISP (of other sources 24) used by thecardholder. In other embodiments, the chargeback fraud factors 246 mayinclude more, fewer and/or different factors than those shown in FIG.4C.

The skimming factors 248 may include: (1) the number (X) of earliertransactions in which the card used for the transaction at issue wasused at an ATM machine or a gas station pump within the 10 days prior tothe transaction at issue; and/or (2) whether the transaction at issueoriginated from an IP address not associated with the cardholder. Forexample, external data collection unit 42 of FIG. 1 may retrievetransaction data indicating that certain past purchases were made usinggas station pump card readers, and/or indicating that the card was usedfor one or more ATM withdrawals, from account records database 30,and/or may retrieve the originating IP address from the one of merchantcomputing systems 22 associated with the merchant involved in thetransaction at issue. In other embodiments, the skimming factors 248 mayinclude more, fewer and/or different factors than those shown in FIG.4C.

Generally, the data indicative of whether the circumstance correspondingto each of counterfeit factors 242, account takeover factors 244,chargeback fraud factors 246 and/or skimming factors 248 is present/truefor a particular transaction may be included in the first account data150 described above in connection with FIG. 3C, for example.

As is also seen in FIG. 4C, each of the counterfeit factors 242, accounttakeover factors 244, chargeback fraud factors 246 and skimming factors248 may be associated with a particular score or weighting value. Thefactors for each classification (counterfeit, account takeover,chargeback fraud, skimming) may be used to calculate a total scorespecific to that classification. In the rule set 240 shown in FIG. 4C,for example, a counterfeit score may be calculated based upon which offactors 242 are, or are not, present, an account takeover score may becalculated based upon which of factors 244 are, or are not, present, andso on. In some embodiments, certain factors may instead be associatedwith negative scores, and/or certain factors (e.g., the first ofskimming factors 248 shown in FIG. 4C) may be associated with metrics oralgorithms that determine how heavily those factors are weighed.

For each classification/category, the rule set 240 may output the totalscore, a normalized total score, an indication of whether the totalscore exceeded a threshold, a probability calculated based upon thetotal score, and/or some other indicator or measure of the likelihoodthat fraud of that particular type/class occurred in connection with thetransaction. In the example shown in FIG. 4C, it can be seen that largerscores generally correspond to a greater probability that the respectiveclassification is accurate. Referring back to FIG. 3C, theclassification at process stage 152 may be the classification having thehighest score and/or probability under rule set 240, or may include thescore and/or probability for each classification, the top threeclassifications, etc.

D. Exemplary Application Fraud Detection Rule Set

Referring now to FIG. 4D, an exemplary rule set 260 may use onlinesearch information (e.g., search terms, search results, clicked/selectedsearch results, etc.) to detect whether an application was fraudulent(e.g., not populated and/or submitted by the purported applicant). Therule set 260 may have been generated at process stage 164 of FIG. 3D,for example. The rule set 260 may be incorporated into a review processthat is generally applied to all applications received by a particularentity or anti-fraud service, or a review process applied only to thoseapplications that were flagged by a preliminary fraud alert, forexample.

The factors considered under the rule set 260 may generally be probativeof whether the person that submitted the application (e.g., via a webbrowser, a dedicated application, as an email attachment, by snail mail,etc.) had performed one or more online searches indicating that he orshe was trying to learn more about the purported applicant in order topopulate particular fields of the application (e.g., a “home address”field, “employment history” fields, etc.). The “purported applicant” maybe a person whose name appears in a name and/or signature field of theapplication, for example.

As seen in FIG. 4D, the factors of exemplary rule set 260 may include:(1) whether the applicant used search terms that included the name ofthe purported applicant; (2) whether the search terms also included thewords “address” or “residence” (and possibly other synonyms ornear-synonyms); and/or (3) whether the search terms also included thewords “employer,” “job” and/or “career” (and possibly other synonyms ornear-synonyms). In other embodiments, the rule set 260 may include more,fewer and/or different factors than those shown in FIG. 4D. For example,the rule set 260 may include one or more factors relating to whichsearch results appeared and/or were selected (e.g., “clicked” on afterappearing on a user interface) by the applicant.

Generally, the data indicative of whether the circumstancescorresponding to the factors of rule set 260 are present/true for aparticular applicant may be included in the first applicant searchhistory data 170 described above in connection with FIG. 3D. Forexample, external data collection unit 42 of FIG. 1 may obtain thesearch terms, search results, search result user selections, etc.,needed to determine whether the various factors exist, from theapplicant's computing device (e.g., similar to one of cardholdercomputing devices 20) and/or from an ISP of other sources 24. Access tosuch information may be made a condition of having the application beconsidered, for example.

As is also seen in FIG. 4D, each of the factors of rule set 260 may beassociated with a particular score or weighting value. A total score maythen be calculated based upon which factors are, or are not, present. Insome embodiments, certain factors may instead be associated withnegative scores, and/or certain factors may be associated with metricsor algorithms that determine how heavily those factors are weighed.

The rule set 260 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the existence or likelihood of applicationfraud. In the example shown in FIG. 4D, it can be seen that largerscores may generally correspond to a greater probability that theapplication was not populated and/or submitted by the purportedapplicant.

E. Exemplary Fraud Dispute Resolution Rule Set

Referring now to FIG. 4E, a flow diagram illustrates at least a portionof a process flow 270 implementing an exemplary rule set for frauddispute, or potential fraud dispute, resolution (e.g., a rule setgenerated at process stage 184 of FIG. 3E). The process flow 270 may beused to help resolve a dispute over a contested transaction, or to helpa customer recall an unrecognized transaction, for example. FIG. 4Eillustrates a process flow, rather than just a set of factors, in orderto better illustrate an example process for generating queries basedupon the generated rules, according to one embodiment. The process flow270 may correspond to a particular embodiment and scenario in which thetransaction subject to dispute or potential dispute is a credit or debitcard transaction.

In the exemplary process flow 270, the rule set may specify that aprocess stage 272 determines whether the transaction was a “cardpresent” transaction. If not, the rule set may specify that the flowproceed directly to a process stage 280. If so, however, the rule setmay specify that the flow instead proceeds to a process stage 274.

The rule set may also specify that process stage 274 determines whetherat least one other transaction associated with the cardholder's accountoccurred within some threshold number of hours (X) of the transaction atissue. If not, the rule set may specify that the flow proceeds directlyto process stage 280. If so, however, the rule set may specify that theflow instead proceeds to a process stage 276.

Process stage 276 may generate one or more location-related queriesusing transaction data associated with the cardholder's account. Thequeries may ask, for example, whether the cardholder was in (or near)one or more particular geographic areas or locations at various times.If the transaction at issue occurred in San Francisco, for example, witha first other “card present” transaction occurring in Santa Rosa fourhours earlier and a second other “card present” transaction occurring inSan Jose two hours later, process stage 276 may generate one or morequeries asking whether the cardholder made or authorized the earlierand/or later transactions, and/or whether the cardholder traveled on aroute from Santa Rosa to San Jose that passed through San Francisco,etc.

In some embodiments, the location-related queries are generated basedupon data associated with events or circumstances other thantransactions. For example, if the transaction at issue occurred inSarasota, Fla., and the data considered under the rule set indicatesthat the cardholder checked in to a flight to Tampa, process stage 276may generate one or more queries asking whether the cardholder completedthe flight, where the cardholder went after landing in Tampa, etc.

The rule set may also specify that process stage 280 determines whetherthe transaction at issue is associated with a billing alias that isdissimilar to the name of the merchant involved in the transaction. Forexample, the computing system of the merchant (e.g., one of merchantcomputing systems 22 of FIG. 1) may have sent to FAMS 14 a transactionrecord that identified the merchant by the alias, and was presented tothe cardholder as an online or paper account statement. Thedetermination at process stage 280 may use the billing alias to identifya legal and/or common name of the merchant (e.g., using a relationaldatabase stored in AFSS12 or FAMS 14), and determine that there is atleast some threshold level of dissimilarity (e.g., based upon differenceof characters, character ordering, etc.) between the billing alias andthe merchant name.

If the billing alias and merchant name are not sufficiently dissimilar,the rule set may specify that the flow proceeds directly to a processstage 284. If sufficiently dissimilar, however, the rule set may specifythat the flow instead proceeds to a process stage 282. Process stage 282may generate a query relating to the billing alias that was presented tothe cardholder. For example, the query may ask whether the cardholder isaware that the billing alias is used by that particular merchant. Insome embodiments, process stage 282 may instead generate a message thatsimply informs the cardholder that the billing alias corresponds to themerchant, without posing a question.

The rule set may specify that process stage 284 generates one or moredefault queries. For example, one default query may ask whether thecardholder lent his or her card to a friend or family member around thetime of the transaction. In some embodiments and/or scenarios, processstage 284 may be omitted from process flow 270. Generally, the queries(and possibly non-query messages) generated in process flow 270 mayserve to help the cardholder recall whether the transaction was made orauthorized, and/or process flow 270 may prompt the cardholder forresponses that are considered by others (e.g., personnel of an entityassociated with FAMS 14 of FIG. 1) to determine whether the transactionwas likely fraudulent.

Although not shown in FIG. 4E, in some embodiments process flow 270 mayinclude a number of iterative stages in which responses are receivedfrom the cardholder (e.g., from the respective one of cardholdercomputing devices 20 in FIG. 1) and used to generate additional, moredetailed questions for the cardholder. For example, if a first queryasks whether the cardholder recalls personally making another “cardpresent” transaction that occurred at a nearby time and place, and thecardholder responds “no,” a new query may be generated asking whetherthe cardholder recalls personally making the next closest transaction(in terms of time and/or location).

F. Exemplary Document Fraud Detection Rule Set

Referring next to FIG. 4F, an exemplary rule set 290 (e.g., generated atprocess stage 204 of FIG. 3F) may use various factors relating to animaged (e.g., photographed or scanned) physical document to determinewhether the document should be flagged as a candidate for a morein-depth (e.g., manual) analysis/review for fraud purposes. The rule set290 may correspond to a particular embodiment and scenario in which thedocument is one that includes at least a signature field (e.g., apersonal check, a driver's license, etc.).

The factors considered under the rule set 290 may include a number ofcounterfeit factors 292 and a number of forgery factors 294, each ofwhich may be evaluated by image analysis unit 52 of FIG. 1 using one ormore image processing techniques. The counterfeit factors 292 may relateto the look, presentation, format and/or structure of the document,while the forgery factors 294 may relate to the substance, style orformat of information entered in one or more fields of the document.

As seen in FIG. 4F, the counterfeit factors 292 may include: (1) whetherone or more absolute or relative dimensions and/or angles of thedocument, or of lines, illustrations, patterns, etc. shown on thedocument (excluding user-entered contents in fields such as thesignature line), are outside one or more predetermined tolerances; (2)whether one or more colors on the document are outside a predeterminedtolerance (e.g., color/frequency range); (3) whether one or more linethicknesses of the document (excluding user-entered field contents) areoutside one or more predetermined tolerances; and/or (4) whether one ormore fonts on the document (excluding user-entered field contents) areoutside one or more predetermined tolerances. For example, imageanalysis unit 52 may determine whether the ratio of the document lengthto the document width is within 0.1% of an expected value. As anotherexample, image analysis unit 52 may determine whether horizontal andvertical lines on the document are within 0.3 degrees of the horizontaland vertical edges of the document, respectively. As yet anotherexample, image analysis unit 52 may determine whether a font used for afield descriptor or other text on the document matches an expected font(e.g., by meeting a similarity threshold measured in any suitablemanner). In other embodiments, the counterfeit factors 292 may includemore, fewer and/or different factors than those shown in FIG. 4F.

The forgery factors 294 may include: (1) whether a signature entered ina signature field of the document match is outside a predeterminedtolerance (e.g., using any suitable signature recognition technique);(2) whether handwriting entered in one or more fields of the document isoutside a predetermined tolerance (e.g., by applying a suitablehandwriting recognition technique); and/or (3) whether the format ofinformation entered by a user in one or more fields does not match anexpected format (e.g., using “9.12.16” rather than the expected“9/12/2016,” as established based upon other documents known to havebeen populated and/or submitted by the purported applicant). In otherembodiments, the forgery factors 294 may include more, fewer and/ordifferent factors than those shown in FIG. 4F.

Generally, the data indicative of whether the circumstancescorresponding to counterfeit factors 292 and/or forgery factors 294 arepresent/true for a particular document may be included in the firstdocument image data 210 described above in connection with FIG. 3F.

As is also seen in FIG. 4F, each of the counterfeit factors 292 andforgery factors 294 may be associated with a particular score orweighting value. In the rule set 290 shown in FIG. 4F, a total score maybe calculated based upon which factors are, or are not, present. In someembodiments, certain factors may instead be associated with negativescores, and/or certain factors may be associated with metrics oralgorithms that determine how heavily those factors are weighed.

The rule set 290 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the likelihood that the document is fraudulent.Alternatively, the rule set 290 may output a separate total score,normalized score, probability, or other metric, for each of counterfeitfactors 292 and forgery factors 294, with the counterfeit metricindicating the likelihood that the document is a counterfeit and theforgery metric indicating the likelihood that the document wasfraudulently populated by someone other than the purported person (e.g.,by someone other than the person corresponding to the name, signature,address, etc. on the document). In the example shown in FIG. 4F, it canbe seen that larger scores generally correspond to a greater probabilitythat the document is fraudulent. In some embodiments, the rule set 290also includes one or more other types of factors not shown in FIG. 4F,and/or omits either counterfeit factors 292 or forgery factors 294.

V. Exemplary Methods for Fraud Detection & Classification

FIGS. 5-10 depict flow diagrams of various exemplarycomputer-implemented methods that may be implemented by one or morecomponents of AFSS 12 of FIG. 1. In one embodiment, AFSS 12 implementsall of the methods corresponding to FIGS. 5-10. In other embodiments,AFSS 12 implements only a subset (e.g., one, two, etc.) of the methodscorresponding to FIGS. 5-10. Each of the methods described below may beimplemented by fraud detection/classification unit 36 of FIG. 1, forexample.

A. Exemplary False Positive Identification

FIG. 5 illustrates an exemplary computer-implemented method 300 of usingcustomer data to determine that geolocation-based fraud alerts are falsepositives. The method 300 may include, via one or more processors and/ortransceivers (or a trained machine learning program), determiningwhether the electronic fraud alert is geolocation based (block 302), andif so, with customer permission, then receiving customer data (block304), such as via wireless communication or data transmission over oneor more radio links or wireless communication channels. The customerdata may be collected or generated via various processors, transceivers,or sensors associated with mobile devices, smart homes, and/or smartvehicles. The customer data may indicate or be associated withtelematics, online activity, browsing activity, IP address, credit card,customer location, and/or financial transaction data.

The method 300 may include determining whether two or more of thecustomer data sources include customer data indicating or confirmingthat the customer is traveling (block 306). If so, the method 300 mayinclude determining whether the current customer location corresponds tothe financial transaction location (block 308). If so, the method 300may include not transmitting the electronic fraud alert to thecustomer's mobile device and/or flagging the fraud alert as a falsepositive; and if not, then transmitting the electronic fraud alert tothe customer's mobile device (block 310).

FIG. 6 illustrates another exemplary computer-implemented method 320 ofusing customer data to determine whether geolocation-based fraud alertsare false positives. The method 320 may include, via one or moreprocessors and/or transceivers, receiving customer data (such as mobiledevice, smart home, smart vehicle, telematics, online activity, IPaddress, credit card, location, and/or financial transaction data)(block 322), such as via wireless communication or data transmissionover one or more radio links or wireless communication channels. Themethod 320 may include determining whether the customer is travelingusing (or based upon processor analysis of) the customer data (block324), such as by identifying that the current GPS location of thecustomer's mobile device and/or vehicle is outside of the customer'shome address county or city. The method 320 may include receiving anelectronic fraud alert associated with the customer (block 326), such asan alert associated with a potentially unauthorized financialtransaction being charged to the customer. The method 320 may includedetermining whether the reason the electronic fraud alert was generatedwas location-based (block 328), such as processor or machine learningprogram determining that a location associated with the financialtransaction does not match a home address location or home city of thecustomer. If so, and if the customer is determined to be traveling, themethod 320 may include determining whether the current customer GPS orother location, such as determined from mobile device, IP address, orvehicle location, corresponds to the financial transaction location(block 330). If so, the method 320 may further include not transmittingthe electronic fraud alert to the customer's mobile device, and/orflagging the fraud alert as a false positive; and if not, thentransmitting the electronic fraud alert to the customer's mobile device(block 332).

In one aspect, a computer-implemented method of using customer data todetermine that geolocation-based fraud alerts are false positives may beprovided. The method may include (1) determining, via the one or moreprocessors, if an electronic fraud alert is a geolocation-based fraudalert (or otherwise generated based upon an unexpected or abnormaltransaction location), such as by inputting the fraud alert and/orfinancial transaction underlying data into a machine learning programtrained to identify geolocation-based fraud alerts; (2) if theelectronic fraud alert is geolocation-based, then retrieving orreceiving (with customer permission or affirmative consent), via the oneor more processors and/or transceivers, two or more sources of customerdata over one or more radio frequency links; (3) determining, via theone or more processors, if the customer data from two or more sourcesindicate or confirm that the customer is traveling (such as notcurrently at their home address or within a predetermined distance oftheir home address); (4) if the customer data indicates that thecustomer is traveling, then determining, via the one or more processors,whether a current customer location indicated by the customer dataretrieved matches, or corresponds to, the transaction location; and/or(5) if the current customer location corresponds to the transactionlocation, then marking, via the one or more processors, the electronicfraud alert as a false positive and not transmitting the electronicfraud alert to a customer mobile device to reduce an amount of falsepositives that are transmitted to customers.

The method may further include receiving, via one or more processorsand/or transceivers, transaction data associated with a financialtransaction over a wireless communication channel; and inputting, viathe one or more processors, the transaction data into a rules-engine toidentify the financial transaction as potentially fraudulent andgenerate an electronic fraud alert. The customer data may be collectedor generated by a mobile device and/or mobile device sensors, andinclude one or more current or past GPS locations.

The customer data may be collected or generated by a vehicle controlleror processor and/or vehicle-mounted sensors, and include one or morecurrent or past GPS locations. The customer data may be collected orgenerated by a smart home controller and/or home-mounted sensors, andinclude data indicating whether or not a home of the customer ispresently occupied or vacant, and/or how long the home has been vacant.The customer data may include an IP address of a customer computingdevice, and include one or more current or past GPS locations. Thecustomer data may include online, browsing, and/or social media activityreceived from a customer computing device. Additionally oralternatively, the customer data may include vehicle telematics datathat includes one or more past or current GPS locations.

If the current customer location does not match or correspond to thetransaction location, then the method may include marking, via the oneor more processors, the electronic fraud alert as verified andtransmitting the electronic fraud alert to a customer mobile device tofacilitate sending only confirmed fraud alerts to customers. The fraudalert may be determined to be geolocation-based when a financialtransaction location is not within a predetermined distance of acustomer home address. Additionally or alternatively, the fraud alertmay be determined to be geolocation-based when a financial transactionlocation does not correspond to normal travel activity or locationsfrequented by, or associated with, the customer.

In another aspect, a computer system configured to use customer data todetermine that geolocation-based fraud alerts are false positives may beprovided. The computer system may include one or more processors and/ortransceivers configured to: determine if an electronic fraud alert is ageolocation-based fraud alert (or otherwise generated based upon anunexpected or abnormal transaction location); if the electronic fraudalert is geolocation-based, then retrieve or receive (with customerpermission or affirmative consent) via wireless communication or datatransmission two or more sources of customer data over one or more radiofrequency links or wireless communication channels; determine if thecustomer data from two or more sources indicate or confirm that thecustomer is traveling (such as not currently at their home address orwithin a predetermined distance of their home address); if the customerdata indicates that the customer is traveling, then determine whether acurrent customer location indicated by the customer data retrievedmatches, or corresponds to, the transaction location; and/or if thecurrent customer location corresponds to the transaction location, thenmark the electronic fraud alert as a false positive and not transmit theelectronic fraud alert to a customer mobile device to reduce an amountof false positives that are transmitted to customers.

B. Exemplary Use of Cardholder Location to Identify or Prevent Fraud

FIGS. 7 through 10 illustrate exemplary computer-implemented methodsthat use information about the locations of authorized cardholders(e.g., the primary cardholder, or another individual listed on theaccount) to prevent false positive fraud alerts, or to block potentiallyfraudulent financial transactions. FIGS. 7 and 8 correspond tocard-present financial transactions (e.g., where an individual swipesthe card or inserts the card in a chip reader, or where a merchant doesso on behalf of that individual after being handed the card), and FIGS.9 and 10 correspond to online financial transactions (e.g., where anindividual types card information into a website page configured toaccept such information in connection with a desired transaction). Themethods of FIGS. 7 through 10 may be implemented by a card issuer/bankor by another entity (e.g., by an entity associated with FAMS 14 or AFSS12 of FIG. 1), for example.

Generally, the methods of FIGS. 7 and 10 may provide the benefit ofavoiding unnecessary network communications and/or computer processingassociated with false positive fraud alerts, while the methods of FIGS.8 and 9 may provide the benefit of avoiding fraudulent transactions inthe first instance, without requiring more cumbersome and/ortime-consuming techniques (e.g., sending an authorization code to theauthorized cardholder to verify a suspicious transaction). Moreover, allof the methods in FIGS. 7 through 10 may more accurately detect fraud byusing the geographic location of the authorized cardholder inconjunction with the location of the transaction or the location of thecomputer used to enter card information. For example, while a $30 gaspurchase 50 miles from the authorized cardholder's home may not looksuspicious to a fraud detection algorithm, the transaction may becomemuch more suspect if the cardholder is 10 miles away from that gasstation at the time of the purchase. Similarly, an online purchase foran item that the authorized cardholder has often bought in the past maynot look suspicious to some fraud detection algorithms, but may becomemuch more suspect if the authorized cardholder was, at the time the cardinformation was entered at a computer, located a significant distanceaway from that computer. Further, the methods of FIGS. 7 through 10 maydetect and/or prevent fraudulent transactions even when the physicaldebit or credit card has been stolen (as opposed to only copying downthe card number or “skimming,” etc.).

Referring first to FIG. 7, in an exemplary computer-implemented method400, it may be determined that a fraud alert exists for a financialtransaction (block 402). The fraud alert may be an electronic fraudalert generated by the device or system implementing the method 400, orreceived from another device or system (e.g., from a card issuer system,such as FAMS 14 of FIG. 1, via a network such as network 26 of FIG. 1),for example. The financial transaction may be a card-present transactionthat is associated with a debit or credit card account, and waspurportedly entered into by an authorized cardholder associated with theaccount.

A first geographic location, at which information associated with theaccount was obtained, may be determined (block 404). The informationassociated with the account may have been obtained by swiping orinserting the card in a device (e.g., part of one of merchant computingsystems 22 of FIG. 1) in connection with the financial transaction, forexample. In some embodiments and/or scenarios, the first geographiclocation may be identified based upon location information included in afield of transaction data associated with the financial transaction,such as transaction data that was retrieved from an account recordsdatabase (e.g., database 30 of FIG. 1).

In some embodiments and/or scenarios, block 404 may occur prior to block402, in which case block 402 may include comparing the first geographiclocation to a set of one or more locations known to be typical orexpected for the authorized cardholder (e.g., a home address, cityand/or state), and/or may include generating the fraud alert in responseto determining that the first geographic location does not correspond to(e.g., is not at, or not within a threshold distance of) the set oftypical/expected locations.

The time of the financial transaction may also be determined (block406). In some embodiments and/or scenarios, the time may be identifiedbased upon time information (e.g., a time stamp) included in aparticular field of transaction data associated with the financialtransaction, such as the transaction data described above.

It may also be determined, based upon geolocation data indicating one ormore geographic locations of the authorized cardholder (e.g., over aperiod of time), that the authorized cardholder was at a secondgeographic location at the time of the financial transaction (block408). The geolocation data may be time-stamped data received from athird party server with the express consent of the authorizedcardholder, or retrieved from a database in which the data was stored(with the cardholder's express consent) after being received from amobile device of the cardholder, for example. The geolocation data mayinclude GPS data (e.g., collected by a smartphone or other mobile deviceof the authorized cardholder), data indicating identifiers and/or signalstrengths of WiFi access points that were near the cardholder (e.g.,collected by a smartphone or other mobile device of the authorizedcardholder), data indicating that the authorized cardholder had “checkedin” at a particular location (e.g., via a social media or otherapplication), data indicating that the authorized cardholder used asmart appliance at a known location (e.g., at the cardholder's home),and/or other types of data indicative of the cardholder's locations atparticular times. The location of the cardholder at the time of thefinancial transaction may be determined by matching a time-stamp to thetime determined at block 406, using a location with a time-stamp thatcorresponds to a nearest time (e.g., so long as that time is within somethreshold time of the time determined at block 406), or in anothersuitable manner.

It may then be determined that the second geographic locationcorresponds to the first geographic location (block 410). For example,it may be determined at block 410 that the first and second geographiclocations are the same (e.g., the same city), are within a samegeographic territory (e.g., cities within the same state), or are withina threshold distance of each other (e.g., cities or more preciselocations within 50 miles of each other, 100 miles of each other, etc.).

In response to the determination at block 410, the fraud alert may bemarked as a false positive (block 412), such that no fraud alert is sentto the authorized cardholder in connection with the financialtransaction. For example, a “verified” flag or field associated with thefraud alert may be set to a value of “0” or “false” at block 412, and anotification unit (e.g., notification unit 56 of FIG. 1) may decide notto send the fraud alert to the authorized cardholder's mobile deviceand/or other computing device (e.g., as an email or text message) basedupon the flag or field value.

Referring next to FIG. 8, in an exemplary computer-implemented method420, a request to authorize a financial transaction may be received(block 422). The financial transaction may be a card-present transactionthat is associated with a debit or credit card account, and ispurportedly being entered into by an authorized cardholder associatedwith the account. As will be understood from the description thatfollows, the financial transaction, in the method 420, is one that hasnot yet been fully executed. The request may have been automatically ormanually generated by the card issuer when deciding whether to clear thetransaction, or automatically or manually generated by a merchantshortly after receiving credit card information (e.g., by a swipe orinsertion of the card), for example. The request may include the creditcard information (e.g., credit card number, expiration date and/orsecurity code) and/or other information relating to the financialtransaction.

A first geographic location, at which information associated with theaccount was obtained (e.g., by swiping or inserting the card inconnection with the financial transaction), may be determined (block424). Block 424 may be similar to block 404 of the method 400, forexample. In some embodiments and/or scenarios, however, the firstgeographic location is determined by identifying the location asspecified in the request received at block 422.

It may also be determined, based upon geolocation data indicating one ormore geographic locations of the authorized cardholder, that theauthorized cardholder was at a second geographic location at the time ofthe financial transaction (block 426). The geolocation data and/or thesource of such data may be similar to that described above in connectionwith block 408 of the method 400, for example. In some embodimentsand/or scenarios, however, the geolocation data may not be time-stamped,or such time stamps may exist but not be utilized. For example, it maybe known that the financial transaction is currently in process, andtherefore the second geographic location may be the current location ofthe authorized cardholder.

It may then be determined that the second geographic location does notcorrespond to the first geographic location (block 428). For example, itmay be determined at block 428 that the first and second geographiclocations are not the same (e.g., not the same city), are not within asame geographic territory (e.g., not cities within the same state), orare not within a threshold distance of each other (e.g., not cities orother, more specific locations within 50 miles of each other, 100 milesof each other, etc.).

In response to the determination at block 428, the financial transactionmay be prevented from being executed (block 430). If the method 420 isimplemented by a computing system of the card issuer, for example, block430 may include not clearing the financial transaction. As anotherexample, a merchant terminal (e.g., part of one of merchant computingsystems 22 of FIG. 1) sending the request received at block 422 (or thatis otherwise associated with the financial transaction) may be sent afraud alert indicating that the transaction may be fraudulent and/orshould not be completed. In yet another example embodiment, the fraudalert may be sent to a computing system of the card issuer (e.g., if therequest received at block 422 was received from such a computingsystem).

Referring next to FIG. 9, in an exemplary computer-implemented method440, a request to authorize a financial transaction may be received(block 442). The financial transaction may be an online transaction thatis associated with a debit or credit card account, and is purportedlybeing entered into by an authorized cardholder associated with theaccount. As with the method 420, the financial transaction, in themethod 440, is one that has not yet been fully executed. The request mayhave been automatically or manually generated by the card issuer whendeciding whether to clear the transaction, or automatically or manuallygenerated by a merchant shortly after receiving credit card information(e.g., shortly after the merchant computing system received credit cardinformation that was manually entered by a person purporting to be theauthorized cardholder), for example. The request may include the creditcard information (e.g., credit card number, expiration date and/orsecurity code) and/or other information relating to the financialtransaction.

A computing device at which information associated with the card account(e.g., the card number, expiration date, and/or three- or four-digitsecurity code) was entered in connection with the financial transactionmay be identified (block 444). The computing device may be identified byreceiving an IP address of the computing device from the computingsystem of the merchant associated with the financial transaction (eitherdirectly, or via the card issuer), for example.

A first geographic location, at which the computing device identified atblock 444 resides, may be determined (block 446). In some embodimentsand/or scenarios, the first geographic location is determined by usingthe IP address of the computing device. For example, the IP addressitself may indicate physical location (at a high level of generality),or the IP address may be used as a key to a location database thatrelates IP addresses to more specific physical locations. With respectto the latter embodiment, for instance, a computing system implementingthe method 440 may, as a part of its fraud prevention services, askcardholders to voluntarily register any fixed-location computers (e.g.,desktop computers) that they expect to use for online purchases, withthe registration process including sending (from each such computer) amessage specifying the physical location of the computer. In still otherembodiments and/or scenarios, the first geographic location isdetermined by identifying a location specified in the request receivedat block 442, or in another suitable manner.

It may also be determined, based upon geolocation data indicating one ormore geographic locations of the authorized cardholder, that theauthorized cardholder was at a second geographic location at the time ofthe financial transaction (block 448). The geolocation data and/or thesource of such data may be similar to that described above in connectionwith block 408 of the method 400, for example. In some embodimentsand/or scenarios, however, the geolocation data may not be time-stamped,or such time stamps may exist but not be utilized. For example, it maybe known that the financial transaction is currently in process, andtherefore the second geographic location may be the current location ofthe authorized cardholder.

It may then be determined that the second geographic location does notcorrespond to the first geographic location (block 450). Block 450 maybe similar to block 428 of the method 420, for example. In response tothe determination at block 450, the financial transaction may beprevented from being executed (block 452). Block 452 may be similar toblock 430 of the method 420, for example.

Referring next to FIG. 10, in an exemplary computer-implemented method460, it may be determined that a fraud alert exists for a financialtransaction (block 462). The fraud alert may be an electronic fraudalert generated by the device or system implementing the method 460, orreceived from another device or system (e.g., from a card issuer system,such as FAMS 14 of FIG. 1, via a network such as network 26 of FIG. 1),for example. The financial transaction may be an online transaction thatis associated with a debit or credit card account, and is purportedlyentered into by an authorized cardholder associated with the account.

A computing device at which information associated with the card account(e.g., the card number, expiration date, and/or three- or four-digitsecurity code) was entered in connection with the financial transactionmay be identified (block 464). Block 464 may be similar to block 444 ofthe method 440, for example.

A first geographic location, at which the computing device identified atblock 464 resides, may be determined (block 466). In some embodimentsand/or scenarios, the first geographic location may be identified basedupon an IP address, of the computing device, that may be specified in aparticular field of transaction data that is retrieved from an accountrecords database (e.g., database 30 of FIG. 1). In other embodimentsand/or scenarios, the first geographic location itself may be specifiedin such a field.

In some embodiments and/or scenarios, block 466 may occur prior to block462, in which case block 462 may include comparing the first geographiclocation to a set of one or more locations known to be typical orexpected for the authorized cardholder (e.g., a home address, cityand/or state), and/or may include generating the fraud alert in responseto determining that the first geographic location does not correspond to(e.g., is not at, or not within a threshold distance of) the set oftypical/expected locations.

The time of the financial transaction may also be determined (block468). In some embodiments and/or scenarios, the time may be identifiedbased upon time information (e.g., a time stamp) included in aparticular field of transaction data associated with the financialtransaction, such as transaction data that is retrieved from an accountrecords database (e.g., database 30 of FIG. 1).

It may also be determined, based upon geolocation data indicating one ormore geographic locations of the authorized cardholder (e.g., over aperiod of time), that the authorized cardholder was at a secondgeographic location at the time of the financial transaction (block470). Block 470 may be similar to block 408 of the method 400, forexample.

It may then be determined that the second geographic locationcorresponds to the first geographic location (block 472). Block 472 maybe similar to block 410 of the method 400, for example. In response tothe determination at block 472, the fraud alert may be marked as a falsepositive (block 474), such that no fraud alert is sent to the authorizedcardholder in connection with the financial transaction. Block 474 maybe similar to block 412 of the method 400, for example.

VI. Exemplary System for Fraud Detection & Classification

FIG. 11 depicts an exemplary computer system 500 in which the techniquesdescribed herein may be implemented, according to one embodiment. Thecomputer system 500 of FIG. 11 may include a computing device in theform of a computer 510. Components of the computer 510 may include, butare not limited to, a processing unit 520, a system memory 530, and asystem bus 521 that couples various system components including thesystem memory 530 to the processing unit 520. The system bus 521 may beany of several types of bus structures including a memory bus or memorycontroller, a peripheral bus, or a local bus, and may use any suitablebus architecture. By way of example, and not limitation, sucharchitectures include the Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus (also known as Mezzanine bus).

Computer 510 may include a variety of computer-readable media.Computer-readable media may be any available media that can be accessedby computer 510 and may include both volatile and nonvolatile media, andboth removable and non-removable media. By way of example, and notlimitation, computer-readable media may comprise computer storage mediaand communication media. Computer storage media may include volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media may include, but is not limited to, RAM, ROM, EEPROM,FLASH memory or other memory technology, CD-ROM, digital versatile disks(DVD) or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canaccessed by computer 510.

Communication media typically embodies computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave or other transport mechanism, and mayinclude any information delivery media. The term “modulated data signal”means a signal that has one or more of its characteristics set orchanged in such a manner as to encode information in the signal. By wayof example, and not limitation, communication media may include wiredmedia such as a wired network or direct-wired connection, and wirelessmedia such as acoustic, radio frequency (RF), infrared and otherwireless media. Combinations of any of the above are also includedwithin the scope of computer-readable media.

The system memory 530 may include computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 531and random access memory (RAM) 532. A basic input/output system 533(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 510, such as during start-up, istypically stored in ROM 531. RAM 532 typically contains data and/orprogram modules that are immediately accessible to, and/or presentlybeing operated on, by processing unit 520. By way of example, and notlimitation, FIG. 11 illustrates operating system 534, applicationprograms 535, other program modules 536, and program data 537.

The computer 510 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 11 illustrates a hard disk drive 541 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 551that reads from or writes to a removable, nonvolatile magnetic disk 552,and an optical disk drive 555 that reads from or writes to a removable,nonvolatile optical disk 556 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 541 may be connected to thesystem bus 521 through a non-removable memory interface such asinterface 540, and magnetic disk drive 551 and optical disk drive 555may be connected to the system bus 521 by a removable memory interface,such as interface 550.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 11 provide storage of computer-readableinstructions, data structures, program modules and other data for thecomputer 510. In FIG. 11, for example, hard disk drive 541 isillustrated as storing operating system 544, application programs 545,other program modules 546, and program data 547. Note that thesecomponents can either be the same as or different from operating system534, application programs 535, other program modules 536, and programdata 537. Operating system 544, application programs 545, other programmodules 546, and program data 547 are given different numbers here toillustrate that, at a minimum, they are different copies. A user mayenter commands and information into the computer 510 through inputdevices such as cursor control device 561 (e.g., a mouse, trackball,touch pad, etc.) and keyboard 562. A monitor 591 or other type ofdisplay device is also connected to the system bus 521 via an interface,such as a video interface 590. In addition to the monitor, computers mayalso include other peripheral output devices such as printer 596, whichmay be connected through an output peripheral interface 595.

The computer 510 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer580. The remote computer 580 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andmay include many or all of the elements described above relative to thecomputer 510, although only a memory storage device 581 has beenillustrated in FIG. 11. The logical connections depicted in FIG. 11include a local area network (LAN) 571 and a wide area network (WAN)573, but may also include other networks. Such networking environmentsare commonplace in hospitals, offices, enterprise-wide computernetworks, intranets and the Internet.

When used in a LAN networking environment, the computer 510 is connectedto the LAN 571 through a network interface or adapter 570. When used ina WAN networking environment, the computer 510 may include a modem 572or other means for establishing communications over the WAN 573, such asthe Internet. The modem 572, which may be internal or external, may beconnected to the system bus 521 via the input interface 560, or otherappropriate mechanism. The communications connections 570, 572, whichallow the device to communicate with other devices, are an example ofcommunication media, as discussed above. In a networked environment,program modules depicted relative to the computer 510, or portionsthereof, may be stored in the remote memory storage device 581. By wayof example, and not limitation, FIG. 11 illustrates remote applicationprograms 585 as residing on memory device 581.

The techniques for detecting and/or classifying fraud described abovemay be implemented in part or in their entirety within a computer systemsuch as the computer system 500 illustrated in FIG. 11. The computer 510may be included in AFSS 12 of FIG. 1, for example, and/or the remoteapplication programs 585 may include one or more applications of eitherFAMS 14, one of cardholder computing device 20, one of merchantcomputing systems 22, or a computing device of other sources 24.Moreover, the functionality of fraud detection/classification unit 36 ofFIG. 1 may be implemented by one or more of application programs 535and/or other program modules 536. As another example, ML rules database58, account holder behaviors database 60 and/or chargeback rulesdatabase 62 of FIG. 1 may be stored in hard disk drive 541 (e.g., asprogram data 547), magnetic disk 552 and/or optical disk drive 555,and/or the data retrieved by fraud detection/classification unit 36 ofFIG. 1 may be stored in hard disk drive 541 (e.g., as program data 547)and/or RAM 532 (e.g., as program data 537).

VII. Exemplary Method Embodiments

In one aspect, a computer-implemented method of using customer data todetermine that geolocation-based fraud alerts are false positives may beimplemented in one or more servers or other computing devices. Themethod may include (1) determining, by one or more processors, that anelectronic fraud alert is a geolocation-based fraud alert generatedbased upon an unexpected or abnormal transaction location; (2) inresponse to determining that the electronic fraud alert is ageolocation-based fraud alert, obtaining, by the one or more processorsand via one or more radio frequency links, customer data from two ormore sources; (3) determining, by the one or more processors, that thecustomer data from the two or more sources indicates that a customer istraveling; (4) in response to determining that the customer dataindicates that the customer is traveling, determining, by the one ormore processors, that a customer location indicated by the customer datacorresponds to the transaction location; and/or (5) in response todetermining that the customer location corresponds to the transactionlocation, (i) marking, by the one or more processors, the electronicfraud alert as a false positive and (ii) causing, by the one or moreprocessors, the electronic fraud alert to not be transmitted to a mobiledevice of the customer in order to reduce an amount of false positivesthat are transmitted to customers. The method may include additional,fewer or alternative actions, such as any of those discussed elsewhereherein.

For instance, determining that the electronic fraud alert is ageolocation-based fraud alert may include inputting, by the one or moreprocessors, one or both of (i) the electronic fraud alert, and (ii)transaction data corresponding to a financial transaction associatedwith the electronic fraud alert, into a machine learning program that istrained to identify geolocation-based fraud alerts.

Additionally or alternatively, the method may further include obtaining,by the one or more processors and via a wireless communication channel,transaction data corresponding to a financial transaction associatedwith the electronic fraud alert, and/or inputting, by the one or moreprocessors, the transaction data into a rules engine to identify thefinancial transaction as potentially fraudulent and generate theelectronic fraud alert.

Additionally or alternatively, the customer data may be collected orgenerated by one or both of (i) the mobile device and (ii) one or moresensors of the mobile device, and/or may include one or more current orpast GPS locations.

Additionally or alternatively, the customer data may be collected orgenerated by one or both of (i) a vehicle controller or processor and(ii) one or more vehicle-mounted sensors, and/or may include one or morecurrent or past GPS locations.

Additionally or alternatively, the customer data may be collected orgenerated by one or both of (i) a smart home controller and (ii) one ormore home-mounted sensors, and/or may include data indicating one orboth of (i) whether a home of the customer is presently occupied orvacant and (ii) how long the home of the customer has been vacant.

Additionally or alternatively, the customer data may include an IPaddress of a customer computing device, and/or may include one or morecurrent or past GPS locations. Additionally or alternatively, thecustomer data may include one or more of (i) online data received from acustomer computing device, (ii) browsing data received from the customercomputing device, or (iii) social media activity data received from thecustomer computing device. Additionally or alternatively, the customerdata may include vehicle telematics data that includes one or more pastor current GPS locations.

Additionally or alternatively, the method may include: determining, bythe one or more processors, that another electronic fraud alert is ageolocation-based fraud alert generated based upon another unexpected orabnormal transaction location; in response to determining that the otherelectronic fraud alert is a geolocation-based fraud alert, obtaining, bythe one or more processors and via one or more other radio frequencylinks, additional customer data from two or more other sources;determining, by the one or more processors, that the additional customerdata from the two or more other sources indicates that another customeris traveling; in response to determining that the additional customerdata indicates that the other customer is traveling, determining, by theone or more processors, that another customer location indicated by theadditional customer data does not correspond to the other transactionlocation; and/or in response to determining that the other customerlocation does not correspond to the other transaction location, (i)marking, by the one or more processors, the other electronic fraud alertas verified and (ii) causing, by the one or more processors, theelectronic fraud alert to be transmitted to a mobile device of the othercustomer to facilitate sending only confirmed fraud alerts to customers.

Additionally or alternatively, determining that the electronic fraudalert is a geolocation-based fraud alert may include determining thatthe transaction location is not within a predetermined distance of acustomer home address. Additionally or alternatively, determining thatthe electronic fraud alert is a geolocation-based fraud alert mayinclude determining that the transaction location does not correspond totravel activity or locations associated with the customer.

In another aspect, a computer-implemented method of reducing falsepositives among geolocation-based fraud alerts issued in connection withcard-present financial transactions may be implemented in one or moreservers or other computing devices. The method may include: (1)determining, by one or more processors of the one or more servers, thata fraud alert exists for a financial transaction, wherein the financialtransaction (i) is associated with a debit or credit card account and(ii) is a card-present transaction purportedly entered into by anauthorized cardholder associated with the debit or credit card account;(2) determining, by the one or more processors, a first geographiclocation at which information associated with the debit or credit cardaccount was obtained by swiping or inserting a debit or credit card inconnection with the financial transaction; (3) determining, by the oneor more processors, a time of the financial transaction; (4)determining, by the one or more processors and based upon geolocationdata indicating one or more geographic locations of the authorizedcardholder, that the authorized cardholder was at a second geographiclocation at the time of the financial transaction; (5) determining, bythe one or more processors, that the second geographic locationcorresponds to the first geographic location; and/or (6) in response todetermining that the second geographic location corresponds to the firstgeographic location, marking, by the one or more processors, the fraudalert as a false positive such that no fraud alert is sent to theauthorized cardholder in connection with the financial transaction. Themethod may include additional, fewer or alternative actions, such as anyof those discussed elsewhere herein.

For instance, determining the first geographic location may occur priorto determining that the fraud alert exists, and determining that thefraud alert exists may include comparing the first geographic locationto a set of one or more typical locations of the authorized cardholder,and/or generating the fraud alert in response to determining that thefirst geographic location does not correspond to the set of one or moretypical locations.

Additionally or alternatively, the method may further includeretrieving, by the one or more processors and from an account recordsdatabase, transaction data associated with the financial transaction,and/or determining the first geographic location may include identifyingthe first geographic location based upon location information includedin a first field of the transaction data.

Additionally or alternatively, determining the time of the financialtransaction may include identifying the time of the financialtransaction based upon time information included in a second field ofthe transaction data. Additionally or alternatively, determining thatthe authorized cardholder was at the second geographic location at thetime of the financial transaction may include receiving the geolocationdata from a third party server.

Additionally or alternatively, determining that the authorizedcardholder was at the second geographic location at the time of thefinancial transaction may include receiving the geolocation data from amobile device of the authorized cardholder, storing the geolocation datain a database, and/or retrieving the geolocation data from the database.Additionally or alternatively, receiving the geolocation data from amobile device of the authorized cardholder may include receiving GPSlocation data from the mobile device.

Additionally or alternatively, determining that the second geographiclocation corresponds to the first geographic location may includedetermining that the first geographic location and the second geographiclocation are within a threshold distance of each other. Additionally oralternatively, determining that the second geographic locationcorresponds to the first geographic location may include determiningthat the first geographic location and the second geographic locationare within a same geographic territory.

In another aspect, a computer-implemented method of preventingfraudulent card-present financial transactions may be implemented in oneor more servers. The method may include: (1) receiving, by one or moreprocessors of the one or more servers, a request to authorize afinancial transaction, wherein the financial transaction (i) isassociated with a debit or credit card account and (ii) is acard-present transaction purportedly being entered into by an authorizedcardholder associated with the debit or credit card account; (2)determining, by the one or more processors, a first geographic locationat which information associated with the debit or credit card accountwas obtained by swiping or inserting a debit or credit card inconnection with the financial transaction; (3) determining, by the oneor more processors and based upon geolocation data indicating one ormore geographic locations of the authorized cardholder, that theauthorized cardholder was at a second geographic location at a time ofthe financial transaction; (4) determining, by the one or moreprocessors, that the second geographic location does not correspond tothe first geographic location; and/or (5) in response to determiningthat the second geographic location does not correspond to the firstgeographic location, preventing, by the one or more processors, thefinancial transaction from being executed. The method may includeadditional, fewer or alternative actions, such as any of those discussedelsewhere herein.

For instance, determining a first geographic location may includeidentifying a first geographic location specified in the request.Additionally or alternatively, determining that the authorizedcardholder was at the second geographic location at the time of thefinancial transaction may include receiving the geolocation data from athird party server.

Additionally or alternatively, determining that the authorizedcardholder was at the second geographic location at the time of thefinancial transaction may include receiving the geolocation data from amobile device of the authorized cardholder, storing the geolocation datain a database, and/or retrieving the geolocation data from the database.Additionally or alternatively, determining that the second geographiclocation does not correspond to the first geographic location mayinclude one or both of determining that the first geographic locationand the second geographic location are not within a threshold distanceof each other, and determining that the first geographic location andthe second geographic location are not within a same geographicterritory.

Additionally or alternatively, preventing the financial transaction frombeing executed may include one or both of causing a fraud alert to besent to a merchant terminal associated with the financial transaction,and causing a fraud alert to be sent to a computing system of a cardissuer associated with the debit or credit card account.

In another aspect, a computer-implemented method of preventingfraudulent online financial transactions may be implemented in one ormore servers. The method may include: (1) receiving, by one or moreprocessors of the one or more servers, a request to authorize afinancial transaction, wherein the financial transaction (i) isassociated with a debit or credit card account and (ii) is an onlinetransaction purportedly being entered into by an authorized cardholderassociated with the debit or credit card account; (2) identifying, bythe one or more processors, a computing device at which informationassociated with the debit or credit card account was entered inconnection with the financial transaction; (3) determining, by the oneor more processors, a first geographic location at which the computingdevice resides; (4) determining, by the one or more processors and basedupon geolocation data indicating one or more geographic locations of theauthorized cardholder, that the authorized cardholder was at a secondgeographic location at a time of the financial transaction; (5)determining, by the one or more processors, that the second geographiclocation does not correspond to the first geographic location; and/or(6) in response to determining that the second geographic location doesnot correspond to the first geographic location, preventing, by the oneor more processors, the financial transaction from being executed. Themethod may include additional, fewer or alternative actions, such as anyof those discussed elsewhere herein.

For instance, receiving the request to authorize the financialtransaction may include receiving the request to authorize the financialtransaction from a computing system of a merchant associated with thefinancial transaction. Additionally or alternatively, identifying thecomputing device at which information associated with the debit orcredit card account was entered may include receiving an IP address ofthe computing device from the computing system of the merchantassociated with the financial transaction.

Additionally or alternatively, determining the first geographic locationmay include determining the first geographic location by using the IPaddress as a key to a location database. Additionally or alternatively,determining that the authorized cardholder was at the second geographiclocation at the time of the financial transaction may include receivingthe geolocation data from a third party server.

Additionally or alternatively, determining that the authorizedcardholder was at the second geographic location at the time of thefinancial transaction may include receiving the geolocation data from amobile device of the authorized cardholder, storing the geolocation datain a database, and/or retrieving the geolocation data from the database.Additionally or alternatively, receiving the geolocation data from amobile device of the authorized cardholder may include receiving GPSlocation data from the mobile device.

Additionally or alternatively, determining that the second geographiclocation does not correspond to the first geographic location mayinclude one or both of determining that the first geographic locationand the second geographic location are not within a threshold distanceof each other, and/or determining that the first geographic location andthe second geographic location are not within a same geographicterritory.

In another aspect, a computer-implemented method of reducing falsepositives among geolocation-based fraud alerts issued in connection withonline financial transactions may be implemented in one or more servers.The method may include: (1) determining, by one or more processors ofthe one or more servers, that a fraud alert exists for a financialtransaction, wherein the financial transaction (i) is associated with adebit or credit card account and (ii) is an online transactionpurportedly entered into by an authorized cardholder associated with thedebit or credit card account; (2) identifying, by the one or moreprocessors, a computing device at which information associated with thedebit or credit card account was entered in connection with thefinancial transaction; (3) determining, by the one or more processors, afirst geographic location at which the computing device resides; (4)determining, by the one or more processors, a time of the financialtransaction; (5) determining, by the one or more processors and basedupon geolocation data indicating one or more geographic locations of theauthorized cardholder, that the authorized cardholder was at a secondgeographic location at the time of the financial transaction; (6)determining, by the one or more processors, that the second geographiclocation corresponds to the first geographic location; and/or (7) inresponse to determining that the second geographic location correspondsto the first geographic location, marking, by the one or moreprocessors, the fraud alert as a false positive such that no fraud alertis sent to the authorized cardholder in connection with the financialtransaction. The method may include additional, fewer or alternativeactions, such as any of those discussed elsewhere herein.

For instance, determining the first geographic location may occur priorto determining that the fraud alert exists, and determining that thefraud alert exists may include comparing the first geographic locationto a set of one or more typical locations of the authorized cardholder,and/or generating the fraud alert in response to determining that thefirst geographic location does not correspond to the set of one or moretypical locations.

Additionally or alternatively, the method may further includeretrieving, by the one or more processors and from an account recordsdatabase, transaction data associated with the financial transaction,determining the first geographic location may include identifying thefirst geographic location based upon location information included in afirst field of the transaction data, and/or determining the time of thefinancial transaction may include identifying the time of the financialtransaction based upon time information included in a second field ofthe transaction data.

Additionally or alternatively, determining that the authorizedcardholder was at the second geographic location at the time of thefinancial transaction may include receiving the geolocation data from athird party server. Additionally or alternatively, determining that theauthorized cardholder was at the second geographic location at the timeof the financial transaction may include receiving GPS location datafrom a mobile device of the authorized cardholder, storing the GPSlocation data in a database, and/or retrieving the GPS location datafrom the database.

Additionally or alternatively, determining that the second geographiclocation corresponds to the first geographic location may includedetermining that the first geographic location and the second geographiclocation are within a threshold distance of each other. Additionally oralternatively, determining that the second geographic locationcorresponds to the first geographic location may include determiningthat the first geographic location and the second geographic locationare within a same geographic territory.

VIII. Exemplary System Embodiments

In one aspect, a computer system configured to use customer data todetermine that geolocation-based fraud alerts are false positives mayinclude one or more processors and a memory. The memory may storeinstructions that, when executed by the one or more processors, causethe computer system to: (1) determine that an electronic fraud alert isa geolocation-based fraud alert generated based upon an unexpected orabnormal transaction location; (2) in response to determining that theelectronic fraud alert is a geolocation-based fraud alert, obtain, viaone or more radio frequency links, customer data from two or moresources; (3) determine that the customer data from the two or moresources indicates that a customer is traveling; (4) in response todetermining that the customer data indicates that the customer istraveling, determine that a customer location indicated by the customerdata corresponds to the transaction location; and/or (5) in response todetermining that the customer location corresponds to the transactionlocation, (i) mark the electronic fraud alert as a false positive and(ii) cause the electronic fraud alert to not be transmitted to a mobiledevice of the customer in order to reduce an amount of false positivesthat are transmitted to customers. The system may include additional,fewer or alternative components, configurations and/or functionality,such as any of those discussed elsewhere herein.

For instance, the instructions may cause the computing system todetermine that the electronic fraud alert is a geolocation-based fraudalert at least by inputting one or both of (i) the electronic fraudalert, and (ii) transaction data corresponding to a financialtransaction associated with the electronic fraud alert, into a machinelearning program that is trained to identify geolocation-based fraudalerts.

Additionally or alternatively, the instructions may further cause thecomputing system to obtain, via a wireless communication channel,transaction data corresponding to a financial transaction associatedwith the electronic fraud alert, and/or input the transaction data intoa rules engine to identify the financial transaction as potentiallyfraudulent and generate the electronic fraud alert. Additionally oralternatively, the customer data may include vehicle telematics datathat includes one or more past or current GPS locations.

In another aspect, a computer system for reducing false positives amonggeolocation-based fraud alerts issued in connection with card-presentfinancial transactions may include a location database configured tostore geolocation data indicating geographic locations of authorizedcardholders over time, one or more processors, and a non-transitorymemory. The memory may store instructions that, when executed by the oneor more processors, cause the one or more processors to: (1) determinethat a fraud alert exists for a financial transaction, wherein thefinancial transaction (i) is associated with a debit or credit cardaccount and (ii) is a card-present transaction purportedly entered intoby an authorized cardholder associated with the debit or credit cardaccount; (2) determine a first geographic location at which informationassociated with the debit or credit card account was obtained by swipingor inserting a debit or credit card in connection with the financialtransaction; (3) determine a time of the financial transaction; (4)determine, based upon first geolocation data stored in the locationdatabase and indicating one or more geographic locations of theauthorized cardholder, that the authorized cardholder was at a secondgeographic location at the time of the financial transaction; (5)determine that the second geographic location corresponds to the firstgeographic location; and/or (6) in response to determining that thesecond geographic location corresponds to the first geographic location,mark the fraud alert as a false positive such that no fraud alert issent to the authorized cardholder in connection with the financialtransaction. The system may include additional, fewer or alternativecomponents, configurations and/or functionality, such as any of thosediscussed elsewhere herein.

For instance, the instructions may further cause the one or moreprocessors to retrieve, from an account records database, transactiondata associated with the financial transaction, the instructions maycause the one or more processors to determine the first geographiclocation at least by identifying the first geographic location basedupon location information included in a first field of the transactiondata, and/or the instructions may cause the one or more processors todetermine the time of the financial transaction at least by identifyingthe time of the financial transaction based upon time informationincluded in a second field of the transaction data.

Additionally or alternatively, the instructions may cause the one ormore processors to determine that the authorized cardholder was at thesecond geographic location at the time of the financial transaction atleast by receiving the first geolocation data from a mobile device ofthe authorized cardholder, storing the first geolocation data in thelocation database, and/or retrieving the first geolocation data from thelocation database. Additionally or alternatively, receiving the firstgeolocation data may include GPS location data.

Additionally or alternatively, the instructions may cause the one ormore processors to determine that the second geographic locationcorresponds to the first geographic location by at least one ofdetermining that the first geographic location and the second geographiclocation are within a threshold distance of each other, or determiningthat the first geographic location and the second geographic locationare within a same geographic territory.

In another aspect, a computer system for preventing fraudulent onlinefinancial transactions may include a location database configured tostore geolocation data indicating geographic locations of authorizedcardholders over time, one or more processors, and a non-transitorymemory. The memory stores instructions that, when executed by the one ormore processors, may cause the one or more processors to: (1) receive arequest to authorize a financial transaction, wherein the financialtransaction (i) is associated with a debit or credit card account and(ii) is an online transaction purportedly being entered into by anauthorized cardholder associated with the debit or credit card account;(2) identify a computing device at which information associated with thedebit or credit card account was entered in connection with thefinancial transaction; (3) determine a first geographic location atwhich the computing device resides; (4) determine, based upongeolocation data indicating one or more geographic locations of theauthorized cardholder, that the authorized cardholder was at a secondgeographic location at a time of the financial transaction; (5)determine that the second geographic location does not correspond to thefirst geographic location; and/or (6) in response to determining thatthe second geographic location does not correspond to the firstgeographic location, prevent the financial transaction from beingexecuted. The system may include additional, fewer or alternativecomponents, configurations and/or functionality, such as any of thosediscussed elsewhere herein.

For instance, the instructions may cause the one or more processors toreceive the request to authorize the financial transaction from acomputing system of a merchant associated with the financialtransaction. Additionally or alternatively, the instructions may causethe one or more processors to identify the computing device at whichinformation associated with the debit or credit card account was enteredat least by receiving an IP address of the computing device from thecomputing system of the merchant associated with the financialtransaction.

Additionally or alternatively, the instructions may cause the one ormore processors to determine the first geographic location at least bydetermining the first geographic location by using the IP address as akey to a location database. Additionally or alternatively, theinstructions may cause the one or more processors to determine that theauthorized cardholder was at the second geographic location at the timeof the financial transaction at least by receiving the geolocation datafrom either (i) a third party server; or (ii) a mobile device of theauthorized cardholder.

Additionally or alternatively, the instructions may cause the one ormore processors to determine that the second geographic location doesnot correspond to the first geographic location at least by one or bothof determining that the first geographic location and the secondgeographic location are not within a threshold distance of each other,and determining that the first geographic location and the secondgeographic location are not within a same geographic territory.

IX. Exemplary Computer-Readable Medium Embodiments

In one aspect, a non-transitory, computer-readable medium storesinstructions that, when executed by one or more processors, may causethe one or more processors to: (1) determine that an electronic fraudalert is a geolocation-based fraud alert generated based upon anunexpected or abnormal transaction location; (2) in response todetermining that the electronic fraud alert is a geolocation-based fraudalert, obtain, via one or more radio frequency links, customer data fromtwo or more sources; (3) determine that the customer data from the twoor more sources indicates that a customer is traveling; (4) in responseto determining that the customer data indicates that the customer istraveling, determine that a customer location indicated by the customerdata corresponds to the transaction location; and/or (5) in response todetermining that the customer location corresponds to the transactionlocation, (i) mark the electronic fraud alert as a false positive and(ii) cause the electronic fraud alert to not be transmitted to a mobiledevice of the customer in order to reduce an amount of false positivesthat are transmitted to customers. The non-transitory, computer-readablemedium may store instructions that include additional, fewer oralternative functions, such as any of those discussed elsewhere herein.

For instance, the instructions may cause the computing system todetermine that the electronic fraud alert is a geolocation-based fraudalert at least by inputting one or both of (i) the electronic fraudalert, and (ii) transaction data corresponding to a financialtransaction associated with the electronic fraud alert, into a machinelearning program that is trained to identify geolocation-based fraudalerts.

Additionally or alternatively, the instructions may further cause thecomputing system to obtain, via a wireless communication channel,transaction data corresponding to a financial transaction associatedwith the electronic fraud alert, and/or input the transaction data intoa rules engine to identify the financial transaction as potentiallyfraudulent and generate the electronic fraud alert. Additionally oralternatively, the customer data may include vehicle telematics datathat includes one or more past or current GPS locations.

X. Additional Considerations

The following additional considerations apply to the foregoingdiscussion. Throughout this specification, plural instances mayimplement operations or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. These and othervariations, modifications, additions, and improvements fall within thescope of the subject matter herein.

1.-14. (canceled)
 15. A computer-implemented method, implemented in oneor more servers, of reducing false positives among geolocation-basedfraud alerts issued in connection with online financial transactions,the method comprising: identifying, by one or more processors of the oneor more servers, a computing device at which information associated witha debit or credit card account was entered in connection with afinancial transaction, wherein the financial transaction (i) isassociated with the debit or credit card account and (ii) is an onlinetransaction purportedly entered into by an authorized cardholderassociated with the debit or credit card account; retrieving, by the oneor more processors and from a memory, one or more locations previouslyassociated with the authorized cardholder; determining, by the one ormore processors, a first geographic location at which the computingdevice resides; determining, by the one or more processors, that a fraudalert exists for the financial transaction, at least in part bycomparing the first geographic location to the one or more locations,and generating the fraud alert in response to determining that the firstgeographic location does not correspond to the one or more locations;and after determining that the fraud alert exists, determining, by theone or more processors, a time of the financial transaction,determining, by the one or more processors and based upon geolocationdata indicating one or more geographic locations of the authorizedcardholder, that the authorized cardholder was at a second geographiclocation at the time of the financial transaction, determining, by theone or more processors, that the second geographic location correspondsto the first geographic location, and in response to determining thatthe second geographic location corresponds to the first geographiclocation, marking, by the one or more processors, the fraud alert as afalse positive such that no fraud alert is sent to the authorizedcardholder in connection with the financial transaction.
 16. (canceled)17. The computer-implemented method of claim 15, further comprising:retrieving, by the one or more processors and from an account recordsdatabase, transaction data associated with the financial transaction,wherein determining the first geographic location includes identifyingthe first geographic location based upon location information includedin a first field of the transaction data, and wherein determining thetime of the financial transaction includes identifying the time of thefinancial transaction based upon time information included in a secondfield of the transaction data.
 18. The computer-implemented method ofclaim 15, wherein determining that the authorized cardholder was at thesecond geographic location at the time of the financial transactionincludes: receiving the geolocation data from a third party server. 19.The computer-implemented method of claim 15, wherein determining thatthe authorized cardholder was at the second geographic location at thetime of the financial transaction includes: receiving GPS location datafrom a mobile device of the authorized cardholder; storing the GPSlocation data in a database; and retrieving the GPS location data fromthe database.
 20. The computer-implemented method of claim 15, whereindetermining that the second geographic location corresponds to the firstgeographic location includes: determining that the first geographiclocation and the second geographic location are within a thresholddistance of each other.
 21. The computer-implemented method of claim 15,wherein determining that the second geographic location corresponds tothe first geographic location includes: determining that the firstgeographic location and the second geographic location are within a samegeographic territory.
 22. A computer system for reducing false positivesamong geolocation-based fraud alerts issued in connection with onlinefinancial transactions, the computer system comprising: one or moreprocessors; and a non-transitory memory storing instructions that, whenexecuted by the one or more processors, cause the one or more processorsto identify a computing device at which information associated with adebit or credit card account was entered in connection with a financialtransaction, wherein the financial transaction (i) is associated withthe debit or credit card account and (ii) is an online transactionpurportedly entered into by an authorized cardholder associated with thedebit or credit card account, retrieve, by the one or more processorsand from a memory, one or more locations previously associated with theauthorized cardholder; determine a first geographic location at whichthe computing device resides; determine that a fraud alert exists forthe financial transaction, at least in part by comparing the firstgeographic location to the one or more locations, and generating thefraud alert in response to determining that the first geographiclocation does not correspond to the one or more locations, and afterdetermining that the fraud alert exists, determine a time of thefinancial transaction, determine, based upon geolocation data indicatingone or more geographic locations of the authorized cardholder, that theauthorized cardholder was at a second geographic location at the time ofthe financial transaction, determine that the second geographic locationcorresponds to the first geographic location, and in response todetermining that the second geographic location corresponds to the firstgeographic location, mark the fraud alert as a false positive such thatno fraud alert is sent to the authorized cardholder in connection withthe financial transaction.
 23. The computer system of claim 22, wherein:the instructions further cause the one or more processors to retrieve,from an account records database, transaction data associated with thefinancial transaction; the instructions cause the one or more processorsto determine the first geographic location at least by identifying thefirst geographic location based upon location information included in afirst field of the transaction data; and the instructions cause the oneor more processors to determine the time of the financial transaction atleast by identifying the time of the financial transaction based upontime information included in a second field of the transaction data. 24.The computer system of claim 22, wherein the instructions cause the oneor more processors to determine that the authorized cardholder was atthe second geographic location at the time of the financial transactionat least by: receiving the geolocation data from a third party server.25. The computer system of claim 22, wherein the instructions cause theone or more processors to determine that the authorized cardholder wasat the second geographic location at the time of the financialtransaction at least by: receiving GPS location data from a mobiledevice of the authorized cardholder; storing the GPS location data in adatabase; and retrieving the GPS location data from the database. 26.The computer system of claim 22, wherein the instructions cause the oneor more processors to determine that the second geographic locationcorresponds to the first geographic location at least by: determiningthat the first geographic location and the second geographic locationare within a threshold distance of each other.
 27. The computer systemof claim 22, wherein the instructions cause the one or more processorsto determine that the second geographic location corresponds to thefirst geographic location at least by: determining that the firstgeographic location and the second geographic location are within a samegeographic territory.
 28. The computer-implemented method of claim 15,wherein the one or more locations comprise a home address of theauthorized cardholder.
 29. The computer-implemented method of claim 15,wherein the one or more locations comprise a location identified by theauthorized cardholder as an expected location of the authorizedcardholder.
 30. The computer system of claim 22, wherein the one or morelocations comprise a home address of the authorized cardholder.
 31. Thecomputer system of claim 22, wherein the one or more locations comprisea location identified by the authorized cardholder as an expectedlocation of the authorized cardholder.